Open 5iver opened 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?
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?
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.
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.
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_.
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_.
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.
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_.
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>
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_.
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.
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_.
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.
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_.
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.
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_.
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_.
That should be the last one. All four are tested working and now updated.
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_.
Reopening so that this doesn't get lost (see discussion in #880.
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.
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).
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.
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...
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.