Most controllers rebuild their entities when upgraded. Capabilities can change, and the new definition needs to be properly applied. Because you've chosen to add your own attributes to system-defined capabilities, those are not restored when the entity is rebuilt because Reactor knows nothing about them. In fact, to Reactor, they look like attributes from an old definition of the capability that have been removed from the most recent definition. As I've said before, your attributes will eventually be created when the event that writes them (layzspa/message), with a correct payload (e.g. { AIR: 123.456 }), is received by MQTTController. You can wait it out, or force the device to send those events. Or, you could do this the way Reactor expects, which is to define a local capability for yourself (e.g. x_mqtt_tunnus_layzspa) and define your own attributes for all of the things you need. Or, break up your single entity into multiple entities that use the system capabilities unmodified.

@toggledbits, Well, I took a first step. I tried using the docker-compose.yaml file with podman-compose, but it gave me some issues. I fell back on just using docker-compose, and it worked with only a minor hickup. It told me the version tag was depricated and to remove it to prevent problems in the future, so I did so, and it's running without issue. Rules and reactions are working as before, which is fantastic. Reactor on my old server is stopped/disabled, so one more item crossed off. I'm hoping to have the old server fully decommissioned this weekend. At some point, I'll go back and try and get it running with Podman, if it's possible. I can engage their community and see if they have any advice, but right now it's more important for me to turn off my office heater going into summer. The other major advantage is that in theory, I won't have to manually update nodejs each release, which has been kind of a pain lately.

Just bought a new one as well. Looks like it'll probably keep working as long as it doesn't become un-compatible C

@Fanan Great! A little more digging on my end, without a complete picture of your end, leads me to CORS. That is exactly the wording of an error I'd expect from CORS, and since HA Blue proxies for its add-ons, I'm betting that's where the issue lies. I don't know what that means for your (HA + Portainer) configuration, but I'd start with the Portainer add-on's support forums. This isn't really Reactor-related.

@toggledbits While you're at it, could you add to Santa's list a request for a function that, when given two coordinates, returns the distance between them? I'll explain the use case: when Life360 worked on Hubitat, one of the variables was precisely the distance between the device and the point determined as the home. However, as I said, it hasn't worked for a long time. This was one of the reasons for installing Home Assistance, which works perfectly, but it doesn't have this information, so I had to do the calculation. I know, you're going to say what a horrible thing, what a mess, but it's working. I prepared a series of calculations, using the coordinates of my home as a reference, for my phone WIL and my wife's phone ADRI. The phone coordinates come from Life360. [image: 1747788334739-525b8ca4-86c2-424f-a3c6-6b11aba39730-image.png] Next, I have the calculations. [image: 1747788467055-391c3a64-dbf9-4a7d-b01c-2a583a6bc83f-image.png] So, I have the result. [image: 1747788504176-36c24be1-f4ec-426e-af61-485de33457de-image.png] I used this formula Python. from math import radians, sin, cos, sqrt, atan2 def haversine(lat1, lon1, lat2, lon2): R = 6371 # raio da Terra em km dlat = radians(lat2 - lat1) dlon = radians(lon2 - lon1) lat1 = radians(lat1) lat2 = radians(lat2) a = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2 c = 2 * atan2(sqrt(a), sqrt(1 - a)) return R * c # distância em km Thanks.

Well after much trepidation, and some additional work, I think we are complete. After the successful virtualisation of my Home Assistant and Music Server hosts, and a successful POC of the main Vera / MQTT / MSR / everything else box I did some testing with a spare UZB stick to make sure I could connect it to the virtual host. With a long weekend ahead to solve any issues, this morning I bit the bullet and shut down the hardware device, moved the production UZB stick over to the NAS and spun up the VM. It was not entirely smooth as for some reason Z-way-server was saying it wasn't connected and AltUI claimed an authentication issue, but with some judicious restarts and testing, everything that I can think of to test now works! Some of the Z-wave commands from remote controls are a little slow, oddly, but I suspect the network needs to sort itself out as it's nearly two months 'old' Direct control from web interfaces / voice commands seems fine so I'm not overly worried. So, barring any unforseen failures, I have a fully virtualised system. Better even, when reading about the Synology range, I decided to source an older unit as a backup cluster device so I have some serious resilience Thanks for all the support an input! C

For anyone coming on this later, you can't specify ip / port in Z-way server. You need to run socat on the z-way server host as specced here: https://forum.z-wave.me/viewtopic.php?f=3417&t=32593&p=83558&hilit=socat#p83558 If you're using ser2net you shouldn't need to use socat on the host that's serving the stick C

@RHCPNG As @toggledbits notes, I've found myself bouncing around a bit. I've settled on what I call Shared Rules - those that impact all things potentially, at a base level. Wx stuff, HVAC stuff, etc. I kinda branch out from there. Interior lighting, Outdoor lighting, Presence, etc. Sorta using "topics" and then rulesets under them. I'm also linked to our local community center via site-to-site VPN and am using my home MSR instance to control the Hubitat C7 over there for lighting and outdoor fans

@Tom_D please mark issue thread as solved

@mgvra the landing page issue was addressed here as a side note in another issue thread: https://smarthome.community/post/16764

@toggledbits, I tried to go about the way you mentioned, but I don't think it was quite suited for my purpose. The purpose of the rule is to send a notification through Home Assistant to my phone, and I didn't want a delay that I believe your method would have introduced. What I came up with was creating a global variable and a helper rule, that sets the global variable to true when the 300 seconds is exceeded of power being above 3.7. [image: 1744127635657-b0f50fcc-a06f-49a6-9ccb-38f718d7cc42-image-resized.png] [image: 1744127574793-88547953-dbd8-4646-80a9-48b03a6c09ad-image-resized.png] Then there is a Variable Value check in the Triggers of the Notification rule: [image: 1744127400119-8b91b3c4-cc46-44db-a4f1-a76408f7c79b-image-resized.png] The Reaction resets the Global rule back to false, after the cycle is completed. It may not be the most elegant method, but it reduces the false positives on my phone when the cycle selector is bumped. For the same reason, I have the reactor uptime checked, because I would get tons of notifications on my phone when I did an update to MSR, or when my server was rebooted. I know I could completely encapsulate the logic within MSR, but the overly simplistic sensor in HAAS serves it's own purpose in HAAS for my dashboard, and HAAS can't read rule states from MSR, so for my purpose, I already have the simple sensor in place, so why reinvent the wheel?

Hint: for debugging, when you run an action, MQTTController logs the exact topic and full payload being published at INFO level by default. I've used MQTTX, which I can highly recommend

@toggledbits I have indeed used the code... and no, this isn't critical. Once I saw MSR was running and working as intended I moved on. Release AYC. @Fanan Re time sync: I did a apt-get install systemd-timesyncd on the Proxmox host. I've not seen the warning since.

So, an empty string is 200ish, otherwise error/timeout is null? That works, thank you!

First, always look at the logs. I'm 100% certain that "nothing happens" isn't what's in the logs. It looks like the device has separate targetValue values for the white channels, so you may just need to use those. That means for red, green, and blue, you'll use targetValue for the property with a JSON object, but leave the propertyKey blank. For warm white, you use property targetValue with propertyKey zero (0), and for cold white you'll use propertyKey one (1). Edit: look at the logs

I reviewed my Reactor configuration file. Some time ago I had duplicated one of the hubitat device sections in anticipation of making changes to my extended LAN. While one entry was marked as "enabled: false", it seems that MSR did not like the duplicate ID even though the duplicate was disabled. I added and "X" to the "id" and "name" of the duplicated entry and the error messages ceased. Thanks for the help

@toggledbits great! Will this fix make it to the next build?