I mostly agree that the decision to go with openzwave was wrong, especially considering the development base. But the problem with open source is that these things happen, there are no promises of long road maps, milestones or the like for the small projects. What I do not agree with is that the decision to move away from the old z-wave stack was wrong, I think it’s much sounder to have it more modular, instead of some monolithic heap that is much harder to maintain.
I was wary of the openzwave, everything told me to not do that, but the new zwave js is much sounder, and with a lot more people involved. So I did the jump, and it was not a problem, important is to get the device path and the network key, but that’s it, it found the devices I had, gave them odd names 
(no more odd than the old z-wave integration did), so a quick tour through the lovelace panels and node-red, and it’s sorted, less than an hours effort.
are you saying that it kept all connected devices that you had on your stick? something that wasnt possible with the OpenZwave integration as I was told … with regards to renaming and aligning - how many devices do you have out of interest?
Yes, it kept the network, as it is on the stick. Well I have 8 z-wave devices, which are currently being fazed out towards zigbee as funds allow it My lock will probably not be replaced (danalock) as it’s been working completely flawlessly for years.
Any idea when the next minor update will be released ? (Expecting some zwave JS bugfixes)
well thats where it differs - I currently have 81 nodes - I had a closer look at the documentation,
Make a list of what node ID belongs to each device. Your network (Nodes and their config etc) is stored on the stick but the names you gave your devices and entities are not. This step is optional but will save you a lot of time later.
consider each having 2-8 entities - lets say 4 on average thats over 300 entities to edit and align, loads of work renaming and checking that everything still works - nothing you do in an hour.
Probably because the main developer of openzwave has had enough (who can blame him) so the HA team needs something maintained
. Can we revisit the move to qt-openzwave? - Configuration / Z-Wave - Home Assistant Community (home-assistant.io)
There is talk of a migration service so with that many devices you might want to hold off on changing for a bit.
Setting Tado Temperature is still not working. Only the sensors seem to work fine … ;(
there was talk about a migration service to OpenZwave - you see where my original post was coming from?
has the formatting of the section header changed as per this update?
using:
- type: custom:fold-entity-row
head:
type: section
label: Battery levels
padding: 0
entities:
suddenly makes all bold headers, which I didn’t notice before. Since the fold-entity-row hasnt been updated in a while, this would be related to HA 2021.2?
I’ve just updated and see the same now.
AAAAAAH!
I just migrated to OZW last week. Bad timing.
Nevertheless happy to see some progress on the ZWAVE-side. And if ZWAVE-JS is indeed faster and needs less resources than OZW, it is a good thing for my Raspi.
Thanks to all involved!
I wish the docs for the ecobee change were updated to go along with this change to temperature holds. Mine is just holding whatever was called last indefinitely. I really like the way it used to work. There was no update to say how to call these changes. I don’t want this to be the release that makes me restore to an old back up and then just stay there till it breaks. I feel like this implementation was rushed and not thought out.
I had my switches all sitting in a switch.yaml, after the upgrade, none of them show up in HA as entities. switches were learned command from Broadlink RM4 Pro, so I could control my TV from HA
Example of one switch below
- platform: broadlink
host: 10.0.0.60
mac: A0:43:B0:55:22:D5
switches:
sony_power:
friendly_name: "Sony Power"
command_on: "JgCMAE0UJhUSFiYVEhUmFRIWEhUmFRMVEhUSFhMAA1BNFSYWERYmFRMUJhUTFRIVKBMTFRMVERYSAANRThQmFRIWJRYSFSYVEhYSFSYVEhYTFBMVEgADUk4VJhUSFScVEhUmFRIWEhUmFRIVExUSFRMAA1JOFSUWExQmFRMVJRYTFBIWJRYSFRIWEhUSAA0FAAAAAAAAAAAAAA=="
command_off: "JgCMAE0UJhUSFiYVEhUmFRIWEhUmFRMVEhUSFhMAA1BNFSYWERYmFRMUJhUTFRIVKBMTFRMVERYSAANRThQmFRIWJRYSFSYVEhYSFSYVEhYTFBMVEgADUk4VJhUSFScVEhUmFRIWEhUmFRIVExUSFRMAA1JOFSUWExQmFRMVJRYTFBIWJRYSFRIWEhUSAA0FAAAAAAAAAAAAAA=="
Any help would be appreciated
Z-Wave … JS! WoW works like a charm Dockerized, fast as a rocket
OZW is nothing I’ll ever miss.
I love the speed and the configuration-UI design of zwavejs2mqtt. You finally get visual feedback if adding or removing a device was successful. You see the network graph, …
I love it.
Installed core-2021.2.0 on my NUC and getting the following new errors:
Invalid config
The following integrations and platforms could not be set up:
recorder
logbook
history
default_config
Please check your config and logs.
Same errors after installing core-2021.2.1
Any ideas?
Just updated from 2021.2.0 to 2021.2.1… what happend??? HA is snappy as hell. Its crazy ! Faster then a speeding bullet…
Good work
So after migrating from 1.4 to ZwaveJS, I have found that all my Qubino RGBW dimmers now do not function correctly with their respective white value sliders.
Previously before the migration, in order to get a white value slider to appear in the dimmers card, I had to add supported features 177 for each dimmer in customize.yaml. This worked well. But now on ZwaveJS the white value slider, although still present in the dimmers card, only affects the brightness level and not the white value. Basically, only the white leds are always lit rather than the rgb and white leds together when set to what would be say the warm white position on the slider.
Has anyone else come across this?
Hi,
I have this issue when upgrading to this new version. When the recorder.migration migrate the database to version 11.
2021-02-05 21:47:03 WARNING (Recorder) [homeassistant.components.recorder.migration] Database is about to upgrade. Schema version: 10
2021-02-05 21:47:03 INFO (Recorder) [homeassistant.components.recorder.migration] Upgrading recorder db schema to version 11
2021-02-05 21:47:03 DEBUG (Recorder) [homeassistant.components.recorder.migration] Looking up index ix_states_old_state_id for table states
2021-02-05 21:47:03 DEBUG (Recorder) [homeassistant.components.recorder.migration] Creating ix_states_old_state_id index
2021-02-05 21:47:03 WARNING (Recorder) [homeassistant.components.recorder.migration] Adding index `ix_states_old_state_id` to database. Note: this can take several minutes on large databases and slow computers. Please be patient!
2021-02-05 21:47:03 ERROR (Recorder) [sqlalchemy.pool.impl.QueuePool] Exception during reset or similar
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 1276, in _execute_context
self.dialect.do_execute(
File "/usr/local/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 609, in do_execute
cursor.execute(statement, parameters)
pyodbc.ProgrammingError: ('42S11', "[42S11] [FreeTDS][SQL Server]The operation failed because an index or statistics with name 'ix_states_old_state_id' already exists on table 'states'. (1913) (SQLExecDirectW)")
I’m using Ubuntu 20.10 with SQL Server 2017.