search

openhab / org.openhab.binding.zwave

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

Support for the indicator class #690

Open 2mmaz opened 6 years ago

2mmaz commented 6 years ago

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.

If the problem is associated with a device, please provide the following -:

Thanks - Thomas

jakobjp commented 6 years ago

Any progress on this?

jakobjp commented 6 years ago

@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?

cdjackson commented 6 years ago

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.

jakobjp commented 6 years ago

Thanks @cdjackson - Looking forward to it :-)

cdjackson commented 6 years ago

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.

jakobjp commented 6 years ago

@cdjackson I wrote to the manufacturer and asked. It is http://logichome.dk

jakobjp commented 6 years ago

@cdjackson, the manufacturer has responded to me, and says that a testunit can be arranged. I have emailed you regarding a shipping address.

cdjackson commented 6 years ago

Just FYI there I've not received anything for testing at this time...

jakobjp commented 6 years ago

I have just written to the manufacturer to send me an update on the shipping. Will get back when I know more.

jakobjp commented 6 years ago

Device is shipped now. Tracking sent to you @cdjackson via email.

cdjackson commented 6 years ago

Great - thanks.

On 8 Mar 2018, at 10:40, jakobjp notifications@github.com 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.

cdjackson commented 6 years ago

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 -:

Comments appreciated from people who want to use this feature.

kulewski commented 6 years ago

@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?

cdjackson commented 6 years ago

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 notifications@github.com 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.

kulewski commented 6 years ago

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.

andreasbrinch commented 6 years ago

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.

jakobjp commented 6 years ago

@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?)

omatzyo commented 6 years ago

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?

omatzyo commented 6 years ago

@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)

cdjackson commented 6 years ago

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.

cdjackson commented 6 years ago

@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.

omatzyo commented 6 years ago

@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 commented 6 years ago

Can you provide a full debug log of the initialisation.

omatzyo commented 6 years ago

@cdjackson I emailed the log to you. The three nodes that were recreated are node2, node63, node69

cdjackson commented 6 years ago

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+.

omatzyo commented 6 years ago

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.

cdjackson commented 6 years ago

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.

cdjackson commented 6 years ago

@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 ;) ).

omatzyo commented 6 years ago

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: untitled

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>
cdjackson commented 6 years ago

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 notifications@github.com 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.

omatzyo commented 6 years ago

@cdjackson, I am getting the exact same error as before. I emailed you with the full log since startup. Node2 is the one I'm troubleshooting currently.

I did try deleting and re-adding the thing after the newest binding was installed.

cdjackson commented 6 years ago

At the moment the channel is configured as a DecimalType - I’d suggest to see if you can configure an item with this type for now, and we can look to change that later.

On 21 Jul 2018, at 19:22, omatzyo notifications@github.com wrote:

@cdjackson https://github.com/cdjackson, I am getting the exact same error as before. I emailed you with the full log since startup. Node2 is the one I'm troubleshooting currently.

I did try deleting and re-adding the thing after the newest binding was installed.

— 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-406814392, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQw3qcl-zPH8bT8FCucmqYsNl5o1hks5uI3FlgaJpZM4PcgIC.

omatzyo commented 6 years ago

I created a Number item and it is linked to the channel, but when I send a value nothing happens. There is also nothing in the DEBUG or even TRACE log.

omatzyo commented 6 years ago

@cdjackson, is there any other information that would help diagnose this?

cdjackson commented 6 years ago

I don’t really understand how there can be nothing in the debug log unless the command is not getting to the binding. As a minimum, there should be messages logged showing the command is being processed - is there really nothing logged?

On 1 Aug 2018, at 02:40, omatzyo notifications@github.com wrote:

@cdjackson https://github.com/cdjackson, is there any other information that would help diagnose 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-409420824, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_kQ9ZaN5wNzSD98J9vQYQH2uwH-3w6ks5uMQcTgaJpZM4PcgIC.