org.openhab.binding.zwave
org.openhab.binding.zwave copied to clipboard
openhab
Support for the indicator class
We need support for the indicator class in order to operate the LogicSoft ZHC5010 devise properly. It must be possible to link items to indicator classes in order to controle state of the LED, and brigtness of the LED
Currently the status LED on the buttons on the devise can not be set without tricking an event as if the button has been pressed. The status indications of the LED can therefore not be kept in sync with events generated by other trickers in the system.
- OH2 Version: 2.1
If the problem is associated with a device, please provide the following -:
- Device name: LogicSoft ZHC5010
- Device version: ALL
- Link to database:
Thanks - Thomas
@cdjackson, this would really be a great addition, and is needed for advanced use cases with the ZHC5010 Fuga Module (and other devices that have similar LED indicators).
Any update if or when this may be implemented?
At the moment my focus is on weeding out some issues with the development binding - I will try and look at this in a month or so once the dev version is into master.
This is going to be quite a large amount of work as the V2 class is a very large change, with a lot more features than the current V1 implementation.
I've already implemented most of the changes, but can't test! I wonder if someone fancies trying to convince the manufacturer to send me a device for testing? Without this it will be a prolonged trial and error test phase.
@cdjackson I wrote to the manufacturer and asked. It is http://logichome.dk
@cdjackson, the manufacturer has responded to me, and says that a testunit can be arranged. I have emailed you regarding a shipping address.
I have just written to the manufacturer to send me an update on the shipping. Will get back when I know more.
Great - thanks.
On 8 Mar 2018, at 10:40, jakobjp [email protected] wrote:
Device is shipped now. Tracking sent to you @cdjackson https://github.com/cdjackson via email.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/690#issuecomment-371434277, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ8WR3u62KYBD5pUjV-zjVbghSvV_ks5tcPyogaJpZM4PcgIC.
Ok, time to work out what we're going to implement on the user side as I have the CC basically functioning (maybe still some issues, but it's communicating now)...
I plan to implement the following channels -:
- indicator_level - a dimmer channel to set the level or turn the indicator on/off
- indicator_period - a decimal channel to set the flash period
- indicator_flash - a decimal channel to set the number of flashes
- indicator_raw - a string channel that will take a string of some sort (probably json) to set everything at once!
Comments appreciated from people who want to use this feature.
@cdjackson, I have Cooper RF9517 accessory switch. When I switch the main switch from openhab2 I want to update the value of accessory one (if not then one has to click it more than once to toggle). I understand that RF9517 needs an indicator class support. Is this something that belongs to this issue or should I open new one? In the meantime, is there any way to hack it? E.g. make a rule to send a custom zwave command or something like this?
You can discuss it here (see my last post). Currently there’s no way to hack it, but I should be able to get something added to the binding in a week or two (I’d like to have some discussion first so I implement something useful).
On 18 Mar 2018, at 00:04, kulewski [email protected] wrote:
@cdjackson https://github.com/cdjackson, I have Cooper RF9517 accessory switch. When I switch the main switch from openhab2 I want to update the value of accessory one (if not then one has to click it more than once to toggle). I understand that RF9517 needs an indicator class support. Is this something that belongs to this issue or should I open new one? In the meantime, is there any way to hack it? E.g. make a rule to send a custom zwave command or something like this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/690#issuecomment-373962091, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQzz7Sip0fOA6sAFvK38mDBnkA-q1ks5tfaSPgaJpZM4PcgIC.
Great! RF9517 has a on/off led, no brightness control. Please let me know if there is any way I can help, including testing something.
I have had trouble getting the ZHC5010 to work reliably. There is a delay from pushing the button till it reacts. When it works well it is noticeable, but less than a second. When it works badly, it takes tens of seconds. Ideally, I would have it react on button down (and not button up), so I've tried setting long press period to 0 and double press period to 1. Still it reacts on button up, but when it works it is instant. Again, sometimes it doesn't work and several seconds goes by.
To have openhab notified of button presses, I have configured it using the REST api as described here: https://community.openhab.org/t/zhc5010-configuration-tutorial/37858 According to the ZHC5010 manual you should set the association group to 1.0 (node_1_0) but it only works if you set it to 1.1. Is it the binding that misinterprets the sender address of the message and relays everything to endpoint 1.
I can see that you got a hold of your own device, so I hope you can work out how it behaves, and I am happy to assist if I can. About the indicator class I would mainly use the indicator_level channel.
@cdjackson what is the status on the Indicator Class implementation?
(Sorry, I have been "sidetracked" with much work for a few weeks, and am not entirely sure I have missed a release or an update somewhere?)
I think the channels suggested above sound great. I also am planning to use the indicator_level mostly to turn the LED off and on. For a device like the Cooper scene controller RFWC5 which has 5 LEDs that can be manipulated (we had this going in openhab 1 at some point), do we need to think about any additional channels or will we be able to address multiple endpoints?
@cdjackson, I added the indicator_level to the RF9540-N in the database, but I don't think openhab has been configured for it yet. I'm not sure what your timetable is, but I'd love to test it out.
When adding the thing it give the following error:
2018-06-24 17:47:40.344 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channel 'indicator_level' for thing type 'zwave:device:zwave_dev:node128', because channel type 'zwave:indicator_level' could not be found.
I'm using the dev snapshot (2.3.0.201806192227)
I added the indicator_level to the RF9540-N in the database
Correct - this is not supported yet. I will try to get this into the development binding today or tomorrow.
@omatzyo I had a look at what you added to the database, but it's not correct. The type= needs to be an indicator type - please see the list in #944.
I've created a test binding here. You will need to delete the XML for this device before starting with this binding to allow it to reinitialise.
Let me know how it goes - please provide logs if there's an error.
@cdjackson, using the binding here I generated XMLs for 3 different cooper devices (RF9540-N, RFWC5, RF9542). The XML files do not appear to be any different from those genereated with the previous dev binding.
They include:
<nodeInformationFrame>
<commandClass>COMMAND_CLASS_INDICATOR</commandClass>
</nodeInformationFrame>
and
<endpoints class="concurrent-hash-map">
<entry>
<int>0</int>
<endPoint>
<deviceClass>
<endpointId>0</endpointId>
<secureCommandClasses/>
<supportedCommandClasses class="concurrent-hash-map">
<entry>
<commandClass>COMMAND_CLASS_INDICATOR</commandClass>
<COMMAND__CLASS__INDICATOR>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
<supportedIndicatorsInitialised>true</supportedIndicatorsInitialised>
<supportedIndicators/>
</COMMAND__CLASS__INDICATOR>
</entry>
</supportedCommandClasses>
</endPoint>
</entry>
</endpoints>
The log does have this line repeated over and over again...
-------------------------------
2018-07-01 11:56:52.622 [ERROR] [ve.internal.protocol.ZWaveController] - NODE 59: Restore from config: Error deserialising XML file. com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter$UnknownFieldException: No such field org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveIndicatorCommandClass.indicator
---- Debugging information ----
field : indicator
class : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveIndicatorCommandClass
required-type : org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveIndicatorCommandClass
converter-type : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
path : /node/endpoints/entry/endPoint/supportedCommandClasses/entry[31]/COMMAND_CLASS_INDICATOR/indicator
line number : 2117
class[1] : java.util.concurrent.ConcurrentHashMap
converter-type[1] : com.thoughtworks.xstream.converters.collections.MapConverter
class[2] : org.openhab.binding.zwave.internal.protocol.ZWaveEndpoint
class[3] : org.openhab.binding.zwave.internal.protocol.ZWaveNode
version : 1.4.7
-------------------------------
But I don't see this error entry for any of the 3 nodes where I regenerated the XML.
Does this mean that for those devices it would be type=NA? That would be unfortunate for the scene controller, which I was hoping would have an entry for each light.
@cdjackson I emailed the log to you. The three nodes that were recreated are node2, node63, node69
The reason that the XML looks the same is that these devices only support V1 of the indicator command class which doesn't support all the new features that were added to discover the different indicator types.
V1 is supported in the binding, but as I've focussed on V2/V3 features I'd need to remind myself how to define the channels as it less well defined with V1. V1 allows setting of an indicator, but I think just ON/OFF - not all the flashing options etc that are defined in V2+.
My experience so far has only been ON/OFF when I use zway to control. Let me know what you decide and I'll make the changes to the database and test it out.
The database should be ok already (I removed the options). It should be a dimmer type, which allows ON/OFF, but could support dimmers on V1 devices that support it.
I need to make a small update to the binding to support V1 properly so will do this tonight.
@omatzyo the latest security / development binding on the forum should now contain this code -:
https://community.openhab.org/t/oh2-z-wave-refactoring-and-testing-and-security/21653
(download link at the top, but you probably know that already ;) ).
Testing with RF9540-N.
Openhab 2.4.0-SNAPSHOT, Build #1311.
Latest development binding loaded (Active │ 80 │ 2.4.0.201807032158 │ ZWave Binding).
The new channel displays in habmin and is linked to my Dimmer item:
But when I send either level 0 or OFF, nothing happens.
2018-07-14 14:07:29.468 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:zwave_dev:node2:indicator_level --> OFF
2018-07-14 14:07:29.471 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command for unknown channel zwave:device:zwave_dev:node2:indicator_level with OnOffType
2018-07-14 14:07:59.103 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:zwave_dev:node2:indicator_level --> 0
2018-07-14 14:07:59.107 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command for unknown channel zwave:device:zwave_dev:node2:indicator_level with PercentType
There is nothing else going on in the debug logs.
The device xml does now include the following:
<commandClass>COMMAND_CLASS_INDICATOR</commandClass>
<COMMAND__CLASS__INDICATOR>
<version>1</version>
<instances>1</instances>
<versionSupported>1</versionSupported>
<isGetSupported>true</isGetSupported>
<supportedIndicatorsInitialised>true</supportedIndicatorsInitialised>
<supportedIndicators/>
</COMMAND__CLASS__INDICATOR>
Probably this is related to an error I’ve fixed in the last day or so. I will update the dev binding later today, so please try again then. Note that you may need to delete the thing and add it back to get it to pick up the changes (I’m not 100% sure in this instance, but if it doesn’t work still, please try this). If it still doesn’t work, then please check the logs during startup as well as when you send the command.
On 14 Jul 2018, at 19:12, omatzyo [email protected] wrote:
Testing with RF9540-N. Openhab 2.4.0-SNAPSHOT, Build #1311. Latest development binding loaded (Active │ 80 │ 2.4.0.201807032158 │ ZWave Binding).
The new channel displays in habmin and is linked to my Dimmer item: https://user-images.githubusercontent.com/12791488/42727180-c8019218-876f-11e8-8344-3aa98b4774d7.png But when I send either level 0 or OFF, nothing happens.
2018-07-14 14:07:29.468 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:de0bde91:node2:indicator_level --> OFF 2018-07-14 14:07:29.471 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command for unknown channel zwave:device:de0bde91:node2:indicator_level with OnOffType 2018-07-14 14:07:59.103 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:de0bde91:node2:indicator_level --> 0 2018-07-14 14:07:59.107 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Command for unknown channel zwave:device:de0bde91:node2:indicator_level with PercentType There is nothing else going on in the debug logs.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhab/org.openhab.binding.zwave/issues/690#issuecomment-405040489, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ6hBf8OvpUhSXOznm5tFoMb2mKZ5ks5uGjSIgaJpZM4PcgIC.