Advice reqeusted to migrate MSR from Bare Metal to Container

[vezinpi]

@eonnet said in Who are my Home Assistant + ZWave-JS users?:

Hello, i managed to connect the HA add on to reactor.

As I mentionned earlier in this thread, I also had issues with the zwavejs2mqtt HA addon. The only option I found was to remove the addon and install it stand alone but still in Docker.

I am just curious to know your setup and how you manage to make it work still using the HA addon.

Thanks

[toggledbits]

Expect LOTS of device mappings to be off, or very generic. Not all devices follow the Z-Wave spec recommendations, particularly legacy Z-Wave devices, and even some first-generation Plus devices. I imagine this is why the Gen 2 specs are a good bit tighter. Regardless, every oddity and exception has to be handled as what it is, which is why I collect data from the interface. I literally sit and spend hours picking through your devices. On every new release, check those devices that previously didn't seem right. If, after a release or two, things still look or behave oddly, do let me know (specific data, please; if you say "X doesn't work" and nothing else, I will ignore it).

[eonnet]

@vezinpi in addon settings add 3000 port to the host.
And than you can access the zwavejs2mqtt addon via ws://ip:3000

[vezinpi]

@eonnet are you using the supervised version with HAAS os ?

[eonnet]

@vezinpi yes hassos

[vezinpi]

Many thanks

[toggledbits]

@eonnet said in Who are my Home Assistant + ZWave-JS users?:

Hello, i managed to connect the HA add on to reactor. The first thing i noticed is that mappings for fan on ZXT-600 and ZXT-120 IR extender for AC are incorrect, on reactor are as follows: 0-off, 1 - auto, 2 - continuous, 3 - periodic, 4 - low, 5 - medium, 6 - high, in zwavejs web console are 0 - Auto low, 1- Low, 3 - High, 5 - Medium

Reactor has its own set of values for its capabilities. These are mapped (or not) into the ZWave standard values supported by the command class, and/or what the device actually supports. Reactor's list is not limited by what the device does, although choosing values the device doesn't support usually won't do anything (or cause a default to be chosen, device-dependent); this has always been true for all devices on all controllers in Reactor.

EDIT: I see where you are getting the numbers, and that's actually a bug (an ancient one, at that) in the Reaction editor, nothing to do with ZWaveController specifically. That is now fixed both for general release 22053 and zwavejs build 22053.

[toggledbits]

Build 22053:

• Fixes in sync with general release build 22053 -- see BREAKING CHANGE notice there
• More small device tweaks
• The default for capturing the zwave-js logs is now false in config (i.e. it won't capture zwavejs log entries by default now).

[toggledbits]

Build 22054:

• Continued device improvements (lots of work on Aeotec devices among others)

[toggledbits]

Build 22058:

• And more device improvements.
• New "Rename" and "Delete" buttons for entities (in Entities list).

Please note that the Rename button may not modify the on-device name if the device does not support the Node Naming and Location command class. This is probably not terribly importent, as the zwave-js and Reactor device/entity databases keep track of user-set names as well. The Delete button does not exclude a Z-Wave device, it merely removes the device from Reactor's device list. If the device is still in the hub (i.e. its still a valid Z-Wave device), the entity will reappear on the next inventory of the Z-Wave controller. The purpose of this feature is primarily to help in the removal of dead devices (i.e. those excluded from the controller by the user).

[toggledbits]

Build 22067

• A few more device tweaks;
• Performance improvements;
• Update mechanism for data files, so that I can post device updates without having to publish a build.

This version is fully in sync with fixes and improvements in latest release 22067.