I am attempting to synchronize scene settings on multiple Leviton VRC4 4-zone controllers

Setup, Configuration and Use Items & Sitemaps
,
1
  • Platform information:
    • Hardware: x86_64/8 GB/4 TB
    • OS: Ubuntu 22.04.4 LTS (5.15.0-100-generic #110-Ubuntu SMP)
    • Java Runtime Environment: openjdk 17.0.10 2024-01-16
    • openHAB version: 4.1.1 (Build)
  • Issue of the topic: I have three Leviton VRC4 4 zone zone controllers for my kitchen lights controlling 5 dimmer switches. I have configured them to use the scene functionality and I have four scene rules that I activate whenever buttons 1-4 are pressed on any of the three zone controllers. This now works mostly great (I have a 50/50 chance of having a strange delay causing my kitchen lights to come on in a staggered fashion reminding me of a few space science fiction ships) but what I would like is for the scene to be reflected on all the wall panels and not just the one I pressed. If panel one is set to scene 2 and the last update moved the kitchen to scene 3, then when I press scene 2 on panel one again it ignores me instead of moving to scene 2. This is annoying but pretty much a deal breaker for my less technical family members.

I have gone through several iterations over the last months and just recently stumbled on the channels documentation saying I could associate one item with the scene channel from all three things. That worked well but doesn’t send the update commands. As a final attempt, I added an additional channel link to individual items in follow profile. After updating my scene rule to send an update to these new follow-only items, I now see the command logs in debug messages, but the state doesn’t update.

In reading other posts for non OH systems, it seems I might have to send some special codes to the Leviton panels in order to make this happen, but I am trying to stay in configuration land with OH. Any advice will be appreciated. (And, am I supposed to be able to have zone controllers synchronize on a scene_number channel?)

  • Please post configurations (if applicable):
    • Items configuration related to the issue
label: Kitchen Scene
type: Number
category: light
groupNames:
  - kitchen
tags:
  - Kitchen

Default profile channel links from:

  • zwave:device:6adad01ba7:node61:scene_number (Number)
  • zwave:device:6adad01ba7:node83:scene_number (Number)
  • zwave:device:6adad01ba7:node64:scene_number (Number)

“Shadow” items defined using the follow profile for each of the above named KS_Entry, KS_Hall, and KS_BackDoor

  • Rules code related to the issue

I have four rules like the following for scenes 1-off, 2-night, 3-breakfast, and 4-bright

configuration: {}
triggers:
  - id: "5"
    configuration:
      itemName: KitchenScene
      state: "1"
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      considerConditions: true
      ruleUIDs:
        - cd2306a380
    type: core.RunRuleAction
  - inputs: {}
    id: "1"
    configuration:
      itemName: KS_Entry
      command: "1"
    type: core.ItemCommandAction
  - inputs: {}
    id: "3"
    configuration:
      itemName: KS_BackDoor
      command: "1"
    type: core.ItemCommandAction
  - inputs: {}
    id: "4"
    configuration:
      itemName: KS_Hall
      command: "1"
    type: core.ItemCommandAction

This one is for “Bright” RuleUID cd2306a380

items:
  InsideCans_Dimmer: "100"
  OuterCans_Dimmer: "100"
  Nook_Dimmer: "100"
  IslandCans_Dimmer: "100"
  IslandPendantLights_Dimmer: "100"
  CounterLighting_Switch: ON
triggers: []
conditions: []
  • If logs where generated please post these here using code fences:

After adding the follow-items channel link, I was able to hit the sendCommand path in the ThingHandler for Z-Wave. This doesn’t change the LED status lights and each controller still thinks it is in the scene that it was last pressed for.

2024-03-09 15:52:32.085 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2024-03-09 15:52:32.085 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SCENE_ACTIVATION, value=1
2024-03-09 15:52:32.097 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 83: Command received zwave:device:6adad01ba7:node83:scene_number --> 1 [DecimalType]
2024-03-09 15:52:32.098 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Command received zwave:device:6adad01ba7:node61:scene_number --> 1 [DecimalType]
2024-03-09 15:52:32.100 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 64: Command received zwave:device:6adad01ba7:node64:scene_number --> 1 [DecimalType]
2024-03-09 15:52:32.178 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2024-03-09 15:52:32.178 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SCENE_ACTIVATION, value=1
2024-03-09 15:52:32.357 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2024-03-09 15:52:32.357 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SCENE_ACTIVATION, value=1
2024-03-09 15:52:32.496 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2024-03-09 15:52:32.497 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SCENE_ACTIVATION, value=1
2024-03-09 15:52:32.598 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 83: Polling skipped for zwave:device:6adad01ba7:node83:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:52:32.599 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Polling skipped for zwave:device:6adad01ba7:node61:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:52:32.601 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 64: Polling skipped for zwave:device:6adad01ba7:node64:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:52:32.916 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2024-03-09 15:52:32.916 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SCENE_ACTIVATION, value=1
2024-03-09 15:52:47.600 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Polling skipped for zwave:device:6adad01ba7:node61:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:52:47.601 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 64: Polling skipped for zwave:device:6adad01ba7:node64:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:53:02.600 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Polling skipped for zwave:device:6adad01ba7:node61:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:53:02.601 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 64: Polling skipped for zwave:device:6adad01ba7:node64:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:53:17.603 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Polling skipped for zwave:device:6adad01ba7:node61:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:53:17.603 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 64: Polling skipped for zwave:device:6adad01ba7:node64:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:53:32.600 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 61: Polling skipped for zwave:device:6adad01ba7:node61:scene_number on COMMAND_CLASS_BASIC
2024-03-09 15:53:32.601 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 64: Polling skipped for zwave:device:6adad01ba7:node64:scene_number on COMMAND_CLASS_BASIC
2

Welcome. Nice detail in your posting. If I understand correctly (and that’s not a given) you may have a couple of options

  1. change the trigger to item update rather than item change. Since scene 2 was the last scene on that controller, pressing it again is not a change.
  2. Another option is to add send commands to the other devices, so if three is pressed on one the others will be updated to three. This may cause traffic issues because your “3” rule will get executed three times. (probably not the best idea.)
  3. What I have seen in the forum is “resetting the scene” (also via a command) into a non-triggering scene. I don’t know if your devices can accept anything besides 1-4. But you could try commanding “0” after maybe a 1 second delay. That would solve the traffic problem and when scene 2 (or whatever) is pressed again, it would be a “change”
3

Thank you for the welcome, Bob, and for the response!

Here are my attempts:

  • Option 1 - update to update: I just tried this options and did not notice any changes in behavior.
  • Option 2 - force a command to others: That is what I had implemented before, but for some reason the command “is ignored” from my devices. I see the command sent in the log, but am not sure how to watch the ZWave command queue and/or traffic to see if it actually sent. If it did, then maybe my device doesn’t care.
  • Option 3 - I added a new rule with a 2 second delay and then a call to each device with a zero scene. I see command in logs both on the send and in the “command received” from the ThingHandler logs. Sadly, same behavior. I suspect that my devices are either not actually getting the commands, they are ignoring them, or I need the specific message I mention bellow from another post sent.

Additional observations:

  • When I press the desired scene button on a panel that thinks the scene is already active, it simply turns the active LED off. Then when I press it again, the scene transitions. I believe this means that the device itself is not sending an update if it thinks it is already in that scene.
  • I have not yet worked out how to watch the ZWave traffic directly. I thought I was seeing the traffic in logs and events, but I think those are just framework and plugin logs.
  • Looking at the ZWave binding code, I don’t actually see how commands are configured through the XML configs. I would like to update the database if I work out how to do this. Maybe add an additional channel or update the current scene_number definition.

In a bug report by j9brown in node-zwave-js, they were working deep with this particular device. None of these non-standard commands seem to do exactly what I want, though I could try the LED manipulation to see if that pulls the scene along with it. Here is what they posted:

<!-- Indicator Lights -->
  <!-- Use these messages to override the indicator lights.
       91 00 1D 0D 01 00 00 : Reset LEDs to locally controlled operation (default behavior).
       91 00 1D 0D 01 FF xx : Set LEDs by OR-ing together the following bit patterns.
         00000000: button 1 off
         00000001: button 1 green
         00010000: button 1 red
         00010001: button 1 amber
         00000000: button 2 off
         00000010: button 2 green
         00100000: button 2 red
         00100010: button 2 amber
         00000000: button 3 off
         00000100: button 3 green
         01000000: button 3 red
         01000100: button 3 amber
         00000000: button 4 off
         00001000: button 4 green
         10000000: button 4 red
         10001000: button 4 amber
  -->

  <!-- Scene Control -->
  <!-- Use these messages to assign scenes to the controller's buttons.
       When no scene is assigned (default behavior), the controller sends BASIC_SET messages
       to association groups 1 to 4 corresponding to the active button.
       When a scene is assigned, the controller sends scene activations and level change messages
       that offer richer control of the device's behavior.
       The controller has 8 scene groups:
         - Groups 1-4 are triggered when buttons 1-4 are toggled to the left side.
         - Groups 5-8 are triggered when buttons 1-4 are toggled to the right side.
         
       To configure the scenes, send SCENE_CONTROLLER_CONF_SET to associate scenes with
       each scene group.  The simplest solution is to assign scene groups 1-8 to scenes 1-8
       so they are in one-to-one correspondence using the following messages:
         2D 01 01 01 00 : Set scene group 1 to scene 1
         2D 01 02 02 00 : Set scene group 2 to scene 2
         2D 01 03 03 00 : Set scene group 3 to scene 3
         2D 01 04 04 00 : Set scene group 4 to scene 4
         2D 01 05 05 00 : Set scene group 5 to scene 5
         2D 01 06 06 00 : Set scene group 6 to scene 6
         2D 01 07 07 00 : Set scene group 7 to scene 7
         2D 01 08 08 00 : Set scene group 8 to scene 8

       Once this is done, the controller will send SCENE_ACTIVATION_SET to the devices
       in association groups 1-4 whenever their corresponding scenes are triggered.  To handle
       these messages centrally, make sure to associate the primary controller (node 1) with
       association groups 1-4.  The primary controller will then receive messages like this:
         2B 01 S# 00 : Sent by controller when scene S# is triggered

       When you press the up/down level below the scene buttons, the controller will send
       send SWITCH_MULTILEVEL_START_LEVEL_CHANGE and SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE messages
       to the association group corresponding to the most recently activated scene.
         26 04 40 00 : Sent by controller when the down lever is pressed
         26 05       : Sent by controller when the down lever is released
         26 04 00 00 : Sent by controller when the up lever is pressed
         26 05       : Sent by controller when the up lever is released

       After a scene change, the controller sometimes sends SCENE_ACTUATOR_CONF_GET messages
       (2C 02 00) to query the scene configuration of the controlled devices.  The controlled
       devices should reply with SCENE_ACTUATOR_CONF_REPORT (2C 03 <sceneId> FF 00) to confirm
       the scene change.  Ignoring the message works too although the controller seems to ask
       several times after each scene change until it gets the expected reply.

       Scene messages interact with the indicator light change messages described above.
       Turning on and off button LEDs determines whether the controller considers the
       corresponding scenes to be active.
  -->

From this, I will add option 4 and simply add the association groups back in to all four buttons. I want to say I already tried this and the zwave-level

SCENE_ACTUATOR_CONF_GET

never seemed to be sent or maybe just was ignored by the other devices. I’ll let you know how I get on with this. I am very happy to have further collaboration as well.

4

These devices look like a handful :laughing:

Well that is somewhat positive. I read that as on-off-on. From the log is seems to be sending a value with “On” but maybe no message with off. I wonder what sending OFF would do in the rule? would it allow the scene to be sent again on the first press. (is that what you are trying to do?)

The best is to ignore the events log and just use the zwave debug. There is a viewer here that makes it easier to read.

I don’t quite understand this. The channels are updated after a message is received from the device. The XML is really to get the zwave messages displayed properly in OH.

edit: I would also add you can use zwave-js-ui with OH if that appeals. Unlike OH, scenes are not persisted, but I do not know if that will help or hurt your situation.

5

Totally! I feed like I want the embedding code from Leviton…

I’ll play with other state values. Maybe something like OFF will at least clear it. I can then figure out how to make them change state together at my leisure (without overly frustrating my loving users).

The log viewer is great! I am not sure why I didn’t see the zwave commands being logged before. I had tried to use it before and probably wasn’t looking for something so didn’t see the value of the colorings and filtering until I did my normal log methods on the flat file. Very nice work! With it, I was able to quickly see that OHZ binding is already doing what I would have wanted to try. The devices seem to acknowledge over the channel, but still, the devices do not change their internal scene state. I will have to keep looking, but in the meantime, I will train my users to expect to hit the button twice sometimes.

These came through via the associations after initiating scene two on device 64. I only expanded a couple of the rows below before copy/pasting.

12:39:29.800	83	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
12:39:29.956	83	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
12:39:30.124	83	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
12:39:30.266	83	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
12:39:30.637	83	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
12:39:31.456	83	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
12:39:46.800	61	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
01 0B 00 04 00 3D 03 2C 02 00 B6 00 56
12:40:51.480	61	
RX REQ ApplicationCommandHandler SCENE_ACTUATOR_CONF 02 0 /128
01 0B 00 04 00 3D 03 2C 02 00 AE 00 4E

Good call on XML. I was assuming that was actual driver-side functionality vs. connecting to the UI. Looking deeper I have found the message classes and handling and such. Former (recovering) java developer here.

I’ll walk through zwave-js-ui. I have previously used it with HA before being annoyed with HA and finding OH. I believe I had the same challenges from a scene/state perspective, but I’ll do some more reading and see what kind of updates have been done (if any) to support these devices.

Thanks for the tips!

Jason

1 Like
6

Given the end goal here is to set the Item to something different so that going to the same scene a second time works, try using an update instead of a command. This will not go out to the device and only change the state of the Item.

I can’t guarantee this will work as it might change back to on the next polling update but it’s worth a try, particularly if you already have the code written.

Finally, I’ll note that you don’t need a rule for this. You can configure expire on the Item as metadata.

As for the Zwave specific stuff, @apella12 the’s one who is most likely going to get you up and running.

7

Thanks Rich! Updates work on the item and they pretty much stay that way until the next one. I’ll watch for this and see if they switch over a longer period of time. I’ll work with @apella12 as I try to get the physical devices to track the updated scene number.

8

Thanks for the vote of confidence :wink: I hope is not misplaced. With my limited experience with scenes in OH the channel stays on the scene number until it is replaced with another scene number. There is a problem with trying to activate a scene twice from the same controller if the scene was deactivated some other way (like via a sitemap, expired or in this case another controller). Hence my suggestions (at least 1 & 3) because I figured that was the problem here.

Based on the feedback that the controller will repeat the scene if pushed twice. I have another idea to add an off channel. I could draft a test XML, but need the device TYPE:ID as there are two similar devices in the DB. This information will be on the device UI page properties dropdown. Basically I’m thinking that after the button is pressed and the number sent, the rule that fires will turn off the Leviton light via the new OFF channel and, per Rich’s suggestion to just change the item state of all the Leviton controllers. They would appear synchronized both in OH and in the kitchen. Would that work?

If there is further testing, I really need to see unaltered and unfiltered logs to understand if something other than the workaround above could be tried. The zwave thing handler generally works between OH channels and the binding. That log is not showing the messages in byte form that the binding is getting from the device. I also believe the thing handler is reacting to the items in the Follow profile and maybe the association group members because there are too many duplicates). Need to try to simplify to what the device is sending when a button is pressed before trying to build on that (one item, no Association group members). The copy/paste snippet doesn’t look right (it is not sending a scene, but a configuration).

9

Hi Bob, that sounds good. Please find attached the set of logs from my testing yesterday. I am up to 83 nodes on my network. Several are inactive since I have the power in my henhouse turned off. A few are old and removed, so usually don’t show up but some are phantoms that keep coming back to my inbox… Anyway, here is the logfile. Let me know if you wanted something else.
openhab.log.zip.log (936.0 KB)

Change the name back to .zip and unzip.

On the type id, here are the top contenders from the properties page in the UI:

  • modelId: VRCZ4
  • manufacturerId: 001D
  • zwave_manufacturer: 29
  • manufacturerRef: 0701:0206,0702:0209,0702:0261,0801:0206
  • zwave_devicetype: 2049
  • zwave_deviceid: 518

I am willing to try if you are. I should be clear that everything in OH seems like it is behaving properly. It really just is the case that the devices will not update their scene information (which LED is lit and the double click send scenario) based on what the other devices are doing. The Items linked to the scene_number channels all seem to update in the way you would expect.

Let me know if that makes sense or if I should grab any other info. FWIW, I pulled down the container for zwave-js-ui and got it running on podman (had to explicitly add the type=bind on the mount). I’ll plan some time next weekend to try it out following your instructions; ideally following the path where you don’t have to redefine all the labels and rules as I have a few.

Additional note
I opened a support ticket with Leviton since I also have several of their newer switches. I have asked for a configuration guide and described the problem a bit. Hopefully they will be able to respond back with something useful.

10

Thanks for the log file. It is a little hard to figure out without knowing the actions about what was pressed when, but it does give me the general flow.

Here is the marked up XML for your device with the extra basic channel.
vrcz4_0_0.xml (6.1 KB)
This needs to replace the existing XML in the binding following this procedure. Since you have java experience you may have a different way to edit the .jar. The XMLs are not compiled so can be edited in the jar. This shouldn’t mess anything else up in your system.

The test I’m thinking about is to press a button on one of devices and then try to send an OFF from OH to see if it does anything to the light. If it does go out :crossed_fingers: Then change the scene from another device and see if the first device will repeat the scene.

Separately, your network is very busy Two (Edit:Three) suggestions 1) you need to set the binding poll to something like 86400 from 15 seconds on these devices. Leaving the command poll at 2000 ms is fine. 2) Also I’d disable the nightly heal unless you are having problems. (EDIT: especially if you have phantoms or powered devices that are OFF). You can just heal an individual device, if you think that will help. In zwave-js they have dropped the “heal” moniker in favor of “rebuild routes” as Heal implies fixing to many folks and IMO it doesn’t very often. 3) Your Leviton devices keep sending the scene number. Modify your rule to do nothing if the previous scene was the same as the last message you received. You can see this with the log viewer. Should stop the flickering lights

No urgency and if you don’t want to do this that is fine. I think the double press is not that unworkable.

11

Hi Bob, thanks for this! I updated back to 86400 for the few devices it was set on and it feels like things are more responsive again. Thanks for the tips. I’ll put the other two (non) actions in place. I have the house to myself this afternoon, so I’ll be able to try the xml update as well. Will report back on how it goes.

12

Hi @apella12, I copied the ZWave jar and updated the file. I confirmed that it was there and then when running

bundle:update 251 file:///home/jason/OpenHABWork/org.openhab.binding.zwave-4.1.1.jar

I get the command line back. The channels do not show up and when I search for the bundle jar again, it is still the old one. Do I need to do something after updated the osgi bundle with the replacement jar?

13

Did you delete the thing from it’s UI page (not exclude) and then scan again? Other than that I don’t see anything.

1 Like
14

Whew, bad new/good news…

To start with, the fan in my old mac mini 2012 (my OpenHAB+ server) that I had previously replaced started making some severe bearing noise. I pulled it open and lubbed the fan, now it is nice an silent again. I then used my trusty iFixIt kit plus some instructions from the site to disassemble the unibody to retrieve some sort of clip that was rattling around in the body. I wasn’t sure what it was, but I normally consider rattling in a computer case to be bad. Took care of that as well.

The bad news: My server had not been shutting down fully and I had to periodically go up and physically reset it at times. In this case, when I brought it up after my fan/rattle maintenance, the boot process persistently hung right after printing out the I915 message. Either I am stuck on the dreaded embedded GPU hang or something right after that which is not printing is stuck. After spending a little time, I gave up and rebuilt my Ubuntu box on the second hard drive. That came up without issue, but no amount of recovery efforts have yet resulted in booting successfully on my first SSD.

Cautionary tale: All of my backups for openhab were on the first SSD. This would not have been a problem before LVM as I would have just mounted it and retrieved what I needed. I will be making backups to a separate place from now on… Right now I can not figure out how to use lvm to “remount” the first ssd and get data off of it. Most sites point me to and lvm recovery process that requires knowledge of the original UUID or a backup file. I might try the fix-boot program that folks are pointing to.

Good news: All told, after rebuilding Ubuntu on my second SSD, I semi-followed your guide @apella12 on Z-Wave JS UI. It is nice every once in a while to rebuild from scratch and apply knowledge gained since the first times. Now my system boots cleanly and I am able to use zwave-js-ui + mosquitto + OpenHAB (milestone release) with Home Assistant discovery enabled. It has taken a couple days to start restoring my rules, but compared to the old way I was doing things, I am pleased to report:

  • I am able to interact much more cleanly with my zwave devices through the UI directly instead of guess and check I was doing through the OH native binding.
  • I can access a much greater range of settings on my devices
  • With greater access to my devices, I was able to delegate some of the rules directly to zwave association groups and for whatever reason, they actually worked vs. doing the same thing (I thought) through OHZW binding. Now I can use OH rules for more complicated scenarios and have most of my system continue working during server maintenance.
  • Redefining my semantic layer let me vastly simplify the hierarchy I had setup and now I am only defining points of interest on my devices instead of the whole thing. I have a much cleaner tree, now.
  • The milestone release has much better handling of updating the semantic tree. Love the work there!
  • I can more effectively use snap, simplifying a lot of my config management.

Work to do:

  • Finish restoring the rules I cared about.
  • Test out my kitchen scene configurations that brought me down this path in the first place.
  • Possibly recover the old boot of my system so I can still test out the new channel in the device config with the native zwave addon.
  • Figure out how to access the data on my SSD #1 since I had some nice code snippets in OpenHAB and then a bunch of other things from my various automation projects.
1 Like
15

There could be a few “warn” messages in the OH log from the HA configs (one reason my post is not written with using them), but as long as you don’t have a thermostat all should work. You can also disable individual HA configs via the zwave-js-ui if they (the warn messages) bother you.

As to the kitchen scenes I’ll suggest a question for Leviton. How does (or can) a Leviton scene controller react when it is a member of another Leviton scene controller. That is, if it is sent Scene Activation CC “3” and it is currently on Scene “2” what will happen?

Lastly I don’t have deep expertise with the ZWave-js driver logs, so those questions, if they arise, should be asked on their github sites. :wink:

Glad you are happy.

1 Like