openhab / org.openhab.binding.zwave

openHAB binding for Z-Wave
Eclipse Public License 2.0
170 stars 202 forks source link

[DEV] VRMX1 (and others) never update scene_number channel #847

Open 5iver opened 6 years ago

5iver commented 6 years ago

I see this with the VRMX1, DZMX1, VRS15, and DZS15, which all support the Scene Activation and Scene Actuator Configuration command classes. I've configured items with the scene_number channel. When manually pressing the paddle, I would expect the scene_number to be updated, but I do not know if these devices would need to be configured in some way to make this happen. This is what I am seeing...

2018-03-04 06:20:12.931 [DEBUG] [otocol.serialmessage.ApplicationUpdateMessageClass] - NODE 26: Application update request. Node information received. Transaction null
2018-03-04 06:20:12.931 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2018-03-04 06:20:12.931 [DEBUG] [otocol.serialmessage.ApplicationUpdateMessageClass] - NODE 26: Application update - no transaction.
2018-03-04 06:20:13.186 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Node is listening - ignore wakeup
2018-03-04 06:20:13.901 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2018-03-04 06:20:13.901 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2018-03-04 06:20:13.901 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_HAIL, endpoint 0
2018-03-04 06:20:13.901 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2018-03-04 06:20:13.901 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_HAIL V0 HAIL
2018-03-04 06:20:13.902 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveDelayedPollEvent
2018-03-04 06:20:13.902 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling intialised at 1800 seconds - start in 75 milliseconds.
2018-03-04 06:20:13.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2018-03-04 06:20:13.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6284b50e.
2018-03-04 06:20:13.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction 1700  ApplicationUpdate.
2018-03-04 06:20:13.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : state >> WAIT_DATA
2018-03-04 06:20:13.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : node  >> 96
2018-03-04 06:20:13.904 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : class >> 130 == null.
2018-03-04 06:20:13.904 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : commd >> 1 == null.
2018-03-04 06:20:13.904 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Command NOT verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6284b50e.
2018-03-04 06:20:13.977 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling...
2018-03-04 06:20:13.978 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling zwave:device:07cb40a2:node26:switch_dimmer
2018-03-04 06:20:13.978 [DEBUG] [.internal.converter.ZWaveMultiLevelSwitchConverter] - NODE 26: Generating poll message for COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-03-04 06:20:13.978 [DEBUG] [col.commandclass.ZWaveMultiLevelSwitchCommandClass] - NODE 26: Creating new message for command SWITCH_MULTILEVEL_GET
2018-03-04 06:20:13.978 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Encapsulating message, endpoint 0
2018-03-04 06:20:13.979 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2018-03-04 06:20:13.979 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2018-03-04 06:20:13.979 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling zwave:device:07cb40a2:node26:switch_dimmer
2018-03-04 06:20:13.979 [DEBUG] [nding.zwave.internal.converter.ZWaveBasicConverter] - NODE 26: Generating poll message for COMMAND_CLASS_BASIC endpoint 0
2018-03-04 06:20:13.980 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Encapsulating message, endpoint 0
2018-03-04 06:20:13.980 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2018-03-04 06:20:13.980 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Command Class COMMAND_CLASS_BASIC is NOT required to be secured
2018-03-04 06:20:13.980 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling zwave:device:07cb40a2:node26:scene_number
2018-03-04 06:20:13.981 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Polling zwave:device:07cb40a2:node26:sensor_binary
2018-03-04 06:20:13.981 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Adding to device queue
2018-03-04 06:20:13.981 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Added to queue - size 65
2018-03-04 06:20:13.982 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Adding to device queue
2018-03-04 06:20:13.982 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Added to queue - size 66
2018-03-04 06:20:20.860 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == true, frequentlyListening == false, awake == false
2018-03-04 06:20:20.863 [DEBUG] [g.openhab.binding.zwave.handler.ZWaveSerialHandler] - NODE 26: Sending REQUEST Message = 01 09 00 13 1A 02 20 02 25 ED 17
2018-03-04 06:20:20.878 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 26: sentData successfully placed on stack.
2018-03-04 06:20:20.881 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: TID 1715: Transaction not completed
2018-03-04 06:20:20.896 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 26: SendData Request. CallBack ID = 237, Status = Transmission complete and ACK received(0)
2018-03-04 06:20:20.897 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2018-03-04 06:20:20.902 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Response processed after 35ms
2018-03-04 06:20:20.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: TID 1715: Transaction completed
2018-03-04 06:20:20.903 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: notifyTransactionResponse TID:1715 DONE
2018-03-04 06:20:20.905 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-03-04 06:20:20.906 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2018-03-04 06:20:20.907 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2018-03-04 06:20:20.907 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2018-03-04 06:20:20.907 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2018-03-04 06:20:20.908 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_BASIC V0 BASIC_REPORT
2018-03-04 06:20:20.908 [DEBUG] [ernal.protocol.commandclass.ZWaveBasicCommandClass] - NODE 26: Basic report, value = 0
2018-03-04 06:20:20.909 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-03-04 06:20:20.909 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 0
2018-03-04 06:20:20.910 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:07cb40a2:node26:switch_dimmer to 0 [PercentType]
2018-03-04 06:20:20.911 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2018-03-04 06:20:20.914 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@52be6664.
2018-03-04 06:20:20.929 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: listening == true, frequentlyListening == false, awake == false
2018-03-04 06:20:20.930 [DEBUG] [g.openhab.binding.zwave.handler.ZWaveSerialHandler] - NODE 26: Sending REQUEST Message = 01 09 00 13 1A 02 26 02 25 EE 12
2018-03-04 06:20:20.942 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 26: sentData successfully placed on stack.
2018-03-04 06:20:20.942 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: TID 1714: Transaction not completed
2018-03-04 06:20:20.957 [DEBUG] [ternal.protocol.serialmessage.SendDataMessageClass] - NODE 26: SendData Request. CallBack ID = 238, Status = Transmission complete and ACK received(0)
2018-03-04 06:20:20.958 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2018-03-04 06:20:20.958 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Response processed after 24ms
2018-03-04 06:20:20.958 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: TID 1714: Transaction completed
2018-03-04 06:20:20.958 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: notifyTransactionResponse TID:1714 DONE
2018-03-04 06:20:20.959 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-03-04 06:20:20.974 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Application Command Request (ALIVE:DONE)
2018-03-04 06:20:20.975 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: resetResendCount initComplete=true isDead=false
2018-03-04 06:20:20.975 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2018-03-04 06:20:20.975 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 26: SECURITY not supported
2018-03-04 06:20:20.975 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 26: Received COMMAND_CLASS_SWITCH_MULTILEVEL V1 SWITCH_MULTILEVEL_REPORT
2018-03-04 06:20:20.975 [DEBUG] [col.commandclass.ZWaveMultiLevelSwitchCommandClass] - NODE 26: Switch Multi Level report, value = 0
2018-03-04 06:20:20.975 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-03-04 06:20:20.975 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SWITCH_MULTILEVEL, value = 0
2018-03-04 06:20:20.976 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - NODE 26: Updating channel state zwave:device:07cb40a2:node26:switch_dimmer to 0 [PercentType]
2018-03-04 06:20:20.977 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Commands processed 1.
2018-03-04 06:20:20.978 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@13e84471.
2018-03-04 06:20:20.978 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction 1718  ApplicationCommandHandler.
2018-03-04 06:20:20.978 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : state >> WAIT_RESPONSE
2018-03-04 06:20:20.978 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : node  >> 96
2018-03-04 06:20:20.979 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : class >> 38 == 152.
2018-03-04 06:20:20.979 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Checking transaction : commd >> 3 == 128.
2018-03-04 06:20:20.979 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 26: Ignoring transaction since not waiting for data.

Should the scene_number channel should be updated with the the value coming in from BASIC? Instead, it is updating SWITCH_MULTILEVEL, which was already updated by the report and the poll specifically sent for it. There is also a tick in the db entry to treat SWITCH_MULTILEVEL as BASIC, so maybe that is a factor? The other devices have similar behavior, and also have the treat as basic tick.

cdjackson commented 6 years ago

Is there a config option available in the device? I suspect it might be something that is configurable so it can either send a scene or dimmer?

5iver commented 6 years ago

Not documented... at least that I could find. I plan to speak with Leviton.

If SCENE_ACTIVATION was the one set to Treat as Basic, instead of SWITCH_MULTILEVEL, would that then update the scene_number channel?

cdjackson commented 6 years ago

If SCENE_ACTUATOR was the one set to Treat as Basic, instead of SWITCH_MULTILEVEL, would that then update the scene_number channel?

Yes, but I'm worried that someone else set the multilevel for a reason, and if we change it here, then it will break their config. I seem to have a vague memory about such a discussion in the past.

5iver commented 6 years ago

I'll modify the XML in the jar and see what the impact would be. My guess is that since SWITCH_MULTILEVEL is also being reported separately, it will be behave the same except for SCENE_ACTIVATION being updated by BASIC. I'll also buzz Leviton next week to ask why SCENE_ACTIVATION isn't reported.

cdjackson commented 6 years ago

I suspect this will work. I know that some scene devices report multilevel as basic, and there’s definitely no standard for this so we can’t make general assumptions. I tried checking the docs for the device, but of course, it was slightly less than useful ;)

My only real concern is that there’s no way to change what comes out for basic so that if we change this, it doesn’t screw up someone elses system.

On 10 Mar 2018, at 20:15, Scott Rushworth notifications@github.com wrote:

I'll modify the XML in the jar and see what the impact would be. My guess is that since SWITCH_MULTILEVEL is also being reported separately, it will be behave the same except for SCENE_ACTIVATION being updated by BASIC. I'll also buzz Leviton next week to ask why SCENE_ACTIVATION isn't reported.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372062416, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ5vty33JLhxwJK440DU2FyPWZ3c8ks5tdDRZgaJpZM4SbTn_.

cdjackson commented 6 years ago

Why should they be the same? If the database changed then it will be different right? I assume that in the past there used to be a SENSOR_BINARY channel defined for the channel, and that was removed some time in the past 6 weeks?

The database currently doesn’t have sensor_binary - I guess it was removed. If it should be there, then we can add it back (I’m not sure when it was removed without checking the history which isn’t so quick).

On 11 Mar 2018, at 10:13, Scott Rushworth notifications@github.com wrote:

Shouldn't these files be the same? Where did the SENSOR_BINARY comie from?

https://github.com/openhab/org.openhab.binding.zwave/blob/development/ESH-INF/thing/leviton_vrmx11lz_0_0.xml https://github.com/openhab/org.openhab.binding.zwave/blob/development/ESH-INF/thing/leviton_vrmx11lz_0_0.xml File from 2.3.0.201803041016 jar... leviton_vrmx11lz_0_0.xml.txt https://github.com/openhab/org.openhab.binding.zwave/files/1799943/leviton_vrmx11lz_0_0.xml.txt — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372103931, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQxgpYcdAe8DzCpiQbpIAVUmkPvNuks5tdPjfgaJpZM4SbTn_.

5iver commented 6 years ago

Arg... tried to remove that comment before you saw it. I screwed up. They are the same. I had it open in the wrong branch.

cdjackson commented 6 years ago

I was replying to the email anyway, so removing the comment wouldn’t have helped ;)

On 11 Mar 2018, at 10:24, Scott Rushworth notifications@github.com wrote:

Arg... tried to remove that comment before you saw it. I screwed up. They are the same. I had open in the wrong branch.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372104546, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ7Er68wZBICT-bDVRmztEy3E1omAks5tdPtvgaJpZM4SbTn_.

5iver commented 6 years ago

After removing BASIC completely, SCENE_ACTIVATION was not coming in at all, but MULTILEVEL_SWITCH still was. After adding BASIC to SCENE_ACTIVATION, scene_number is now getting values after manually adjusting the dimmer. MULTILEVEL_SWITCH also still gets values reported, so there shouldn't be any change in functionality. From the results of the testing I've done, I think this would be a safe change to make.

    <channels>
      <channel id="switch_dimmer" typeId="switch_dimmer">
        <label>Dimmer</label>
        <properties>
          <property name="binding:*:PercentType">COMMAND_CLASS_SWITCH_MULTILEVEL</property>
          <property name="binding:Command:OnOffType">COMMAND_CLASS_SWITCH_MULTILEVEL</property>
        </properties>
      </channel>
      <channel id="scene_number" typeId="scene_number">
        <label>Scene Number</label>
        <properties>
          <property name="binding:*:DecimalType">COMMAND_CLASS_SCENE_ACTIVATION,COMMAND_CLASS_BASIC</property>
        </properties>
      </channel>
    </channels>
cdjackson commented 6 years ago

Ok, so I’ve seen nothing then that indicates the multilevel should be linked to basic, so I think this is a safe change to make in the database. If someone complains then we’ll deal with it then.

If you want to update the database, and approve it, I’ll copy it over before I do the update.

Thanks.

On 11 Mar 2018, at 15:11, Scott Rushworth notifications@github.com wrote:

After removing BASIC completely, SCENE_ACTIVATION was not coming in at all, but MULTILEVEL_SWITCH still was. After adding BASIC to SCENE_ACTIVATION, scene_number is now getting values after manually adjusting the dimmer. MULTILEVEL_SWITCH also still gets values reported, so there shouldn't be any change in functionality. From the results of the testing I've done, I think this would be a safe change to make.

<channels>
  <channel id="switch_dimmer" typeId="switch_dimmer">
    <label>Dimmer</label>
    <properties>
      <property name="binding:*:PercentType">COMMAND_CLASS_SWITCH_MULTILEVEL</property>
      <property name="binding:Command:OnOffType">COMMAND_CLASS_SWITCH_MULTILEVEL</property>
    </properties>
  </channel>
  <channel id="scene_number" typeId="scene_number">
    <label>Scene Number</label>
    <properties>
      <property name="binding:*:DecimalType">COMMAND_CLASS_SCENE_ACTIVATION,COMMAND_CLASS_BASIC</property>
    </properties>
  </channel>
</channels>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372122552, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ2lYtySoJtJ2TTCM8zp6ZOwpKosEks5tdT6IgaJpZM4SbTn_.

5iver commented 6 years ago

I've updated and published the dimmer VRMX1 and DZMX1. I'll now test the switches (VRS15 and DZS15) and update them if the results are the same. There are a lot of others though.

cdjackson commented 6 years ago

I’d be a bit careful making a general assumption that all scene controllers do the same thing. If they are all fundamentally the same (eg same manufacturer) then it might be a good assumption, but for sure others will do this differently so I would just do the devices you can test ;)

On 11 Mar 2018, at 16:50, Scott Rushworth notifications@github.com wrote:

I've updated and published the dimmer VRMX1 and DZMX1. I'll now test the switches (VRS15 and DZS15) and update them if the results are the same. There are a lot of others though.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372130004, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ_GcysrXJ1fmaLChimFpUpzpjXqDks5tdVXrgaJpZM4SbTn_.

5iver commented 6 years ago

O yeah! Sorry. I only plan to update the ones I can test. But there are others, so in case someone else complains about scenes not working, this may be the fix.

cdjackson commented 6 years ago

Agreed - I guess if you felt really enthusiastic you could post about this on the forum and see if anyone has devices that need to be fixed… Up to you though ;)

On 11 Mar 2018, at 17:22, Scott Rushworth notifications@github.com wrote:

O yeah! Sorry. I only plan to update the ones I can test. But there are others, so in case someone else complains about scenes not working, this may be the fix.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372132364, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ_UdC7DQaa5QoPXIcVz2TbjqBm3Nks5tdV1HgaJpZM4SbTn_.

5iver commented 6 years ago

The trick will be in having them test it before they update the database and potentially bugger up other people's devices. Just wish there was a clear reason why all of these devices have BASIC set on SWITCH_MULTILEVEL and SWITCH_BINARY. I can't think of a reason why it would ever be needed.

And it looks like kind of a hack to get SCENE_ACTIVATION working. I'm very curious what Leviton will say. Maybe there's something in the MANUFACTURER_SPECIFIC or MANUFACTURER_PROPRIETARY.

cdjackson commented 6 years ago

MANUFACTURER_SPECIFIC is just the manufacturer data. If MANUFACTURER_PROPRIETARY is supported, then this can house custom functions, but it’s more likely that they would have undocumented config commands than going to the trouble of implementing another command class just to enable scenes.

It’s not uncommon for devices to report their prime function using the basic command class, so I don’t think it’s a hack. There’s normally other configuration though that enables “real” scene_activation messages - it would certainly be surprising if there were no other way to get these commands sent…

Let’s see what they come back with.

On 11 Mar 2018, at 17:38, Scott Rushworth notifications@github.com wrote:

The trick will be in having them test it before they update the database and potentially bugger up other people's devices. Just wish there was a clear reason why all of these devices have BASIC set on SWITCH_MULTILEVEL and SWITCH_BINARY. I can't think of a reason why it would ever be needed.

And it looks like kind of a hack to get SCENE_ACTIVATION working. I'm very curious what Leviton will say. Maybe there's something in the MANUFACTURER_SPECIFIC or MANUFACTURER_PROPRIETARY.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372133568, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ5Q-LkYOlNYlLCkC-_AA1KC_BDX2ks5tdWEugaJpZM4SbTn_.

cdjackson commented 6 years ago

I see you’re still making updates - let me know when you’re done and I’ll publish the binding...

On 11 Mar 2018, at 17:38, Scott Rushworth notifications@github.com wrote:

The trick will be in having them test it before they update the database and potentially bugger up other people's devices. Just wish there was a clear reason why all of these devices have BASIC set on SWITCH_MULTILEVEL and SWITCH_BINARY. I can't think of a reason why it would ever be needed.

And it looks like kind of a hack to get SCENE_ACTIVATION working. I'm very curious what Leviton will say. Maybe there's something in the MANUFACTURER_SPECIFIC or MANUFACTURER_PROPRIETARY.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372133568, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ5Q-LkYOlNYlLCkC-_AA1KC_BDX2ks5tdWEugaJpZM4SbTn_.

5iver commented 6 years ago

That should be the last one. All four are tested working and now updated.

cdjackson commented 6 years ago

Great - thanks.

On 11 Mar 2018, at 18:03, Scott Rushworth notifications@github.com wrote:

That should be the last one. All four are tested working and now updated.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/847#issuecomment-372135396, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ17tGH6NkOlFhYg55Td7gp080fPCks5tdWcJgaJpZM4SbTn_.

5iver commented 6 years ago

Reopening so that this doesn't get lost (see discussion in #880.

5iver commented 6 years ago

I neglected to update this issue with the response from Leviton. In regards to...

Dimmers: VRMX1, DZMX1
Switches: VRS15, DZS15

...they confirmed that...

The device only sends the HAIL command and the receiving controller needs to poll the device for status.

So polling code needs to be added to the SCENE_ACTIVATION converter, or polling reenabled for BASIC.

cdjackson commented 6 years ago

Unfortunately it's not possible to poll the SCENE_ACTIVATION command class as the protocol does not provide this feature - it's designed to send only from the device (ie there is only a SET command - not a GET command).

5iver commented 6 years ago

I forgot the specifics of this issue. We can't poll SCENE_ACTIVATION, but we could poll BASIC, which was removed in #880. The devices I use with SCENE_ACTIVATION, and likely any other devices that use it, have Treat as Basic checked in order to use it. This no longer works, since the polling of BASIC was removed.