thecode

I think it would be better to post it on a new thread.

I don't know if this is just coincidence, but after updating the unraid connect plugin my theme reverted to the normal black theme, moreover even the banner disappeared. Theme engine config files were not changed (comparing to a backup), removing and reinstalling it did nothing. What I noticed is that the display settings changed, I could manually update them (for example reselect the banner), but eventually just restored this file from a backup (config\plugins\dynamix\dynamix.cfg)

I don't see it either, however I am not the owner of that app, you better ask in the relevant support thread. This is about Portainer business edition

Thanks for updating back. I was too busy this week and planed to test it over the weekend.

I think this is related to Samba, it is definitely not the famous macvlan call trace

You should not get any macvlan errors on 6.12.4 as far as I understand, can you post a sample log trace here? or diagnostics?

vhost0 replaces br0. virbr0 is provided by libvirt and is used to created a NAT network for VMs. You should only update the interface in VMs (if it doesn't update automatically) to vhost0 if it was br0. There is no preferred default, it depends if you want the VM to run on your network (non-isolated) or run in a separated isolated network.

This is a great release which makes 6.12 so much better.

I have tested the this since early releases and no more macvlan traces, both with bridging disabled and enabled. Great work @bonienl and everyone else who contributed to fixing it

I don't really understand what you want to do, you should add dockers via unraid docker system, this is just for monitoring docker containers

You will need to contact Deconz, you can do it on their Github https://github.com/dresden-elektronik/deconz-rest-plugin or Discord: https://discord.gg/ycPBweQf and debug it with them. There is nothing wrong in this Docker according to the log. They will ask you to enable extra logging which can help understand the issue

There are no errors in the log, can you try to pair/add device?

It looks like it is not related to the docker if that is the case, once it communicates with the dongle everything else is not related to the docker or template. You can try to create an issue here: https://github.com/dresden-elektronik/deconz-rest-plugin If you want you can provide log from the docker console and I can try to see if it shows something which can hint what is the problem.

So what is not working? as I see your device is detected

Start by posting the output from: ls /dev/serial/by-id

Yes, thanks!

Hi, The update to separate apparent power and real in 2023.07.23a is great, however if the UPS capacity is manually adjusted under display settings the footer shows incorrect real power (the value on the dashboard and on the settings page is correct) Example with a UPS that uses the default values: Setting the capacity to "auto" the values are identical: I hope this can be looked at, Thanks

Indeed, tried to look at it, but as you wrote before it needs major rewrite, most of my experience is with backend and not with frontend and I have limited time now, I can fix broken logic, but too busy for a complete rewrite. If someone have time to fix it, I can still validate the changes and release a new version. I will also try to look at it again when I have more time.

3 messages up, this is broken in 6.12, there was an attempt to fix it but it didn't work correctly.

I can confirm the fix works in 6.12.3, I removed the static metric before upgrade and route is set with the correct metric after. Thanks for the efforts resolving this issue.

Many thanks for your helping me debugging this issue. I think that a first step (but not urgent) would be to fix the GUI to reduce confusion. To fixed it, maybe if metric is not explicitly set for br0 it can be automatically set to 1 when the script creates "shim-br0" About making it clear to the user, since the 6.12 Known issues points to your excellent post, I would suggest to edit the post and suggest to first try ipvlan with metric set to 1 for br0. And thanks again 👍

To test my assumption about the interface metric I have manually set the interface metric to 1. With this set to 1 my routing table in the GUI now looks like this: output from route: There may be one little GUI bug since the GUI shows metric as "1" while route shows 0 or 1. With this setting I think the issue of the incomplete arp is fixed for me. I will let it run for 1-2 days to test.

There is one difference between this and my config, my config is missing the default route for the shim-br0:

This doesn't make any sense, how would setting a static IP in unraid (with the same IP) related to the router? If a problem would be when DHCP is used it can explain, but when setting a static IP the router should not have any effect. I have another unraid server which is set to "macvlan" which doesn't suffer from this (with a static IP) and more than 100 network devices and only this server suffer from this problem. I have also tried to setup a linux machine with docker and manually create shim interface (using https://blog.oddbit.com/post/2018-03-12-using-docker-macvlan-networks/) and it did not have any problem. Only this server has the incomplete arp problem and only with ipvlan. I also can't understand why would a switch/router that has both servers connected to it will be missing the arp for one server. I can capture traffic directly on the router to check. I am not the only one having this, not sure if this helps but there is a thread about it on reddit:

To check it I disabled the DHCP from the GUI (set to static), did not change anything else (the DHCP IP is already offered as the correct static IP), rebooted the server, right after reboot the server is missing the arp for br0.