Problems with EUROtronic Technology CometZ Thermostatic Valve

chris · October 13, 2016, 10:23pm

I would try tomorrows version of the binding as I’ve reverted the NIF/Wakeup code. If that doesn’t work, and you’ve tried waking up the device manually, and you still don’t get manufacturer information provided, then get a full log during the initialisation and I’ll take a look…

hermann59 · October 14, 2016, 12:22pm

@chris
Today I did an apt-get update; apt-get upgrade openhab2.
Afterwards, I tried to update the device manually by turning the temperature wheel manually. As a result, paperUI displays the node status as “online” and I get an entry in event.log:

2016-10-14 14:14:19.715 [ItemStateChangedEvent ] - zwave_serial_zstick_157be653371_serial_sof changed from 17 to 18

But the node still has the generic name “Node 2” and is shown as an unknown device. Is it correct, that the ItemStateChangedEvent tells me that the device woke up?

jaydee73 · October 14, 2016, 12:44pm

There seems to be some troubles at the moment with the building process at cloudbees, which could lead to not getting the latest version with apt-get. Or the binding update was made this night after the apt-bundle was created.

You should do a

bundle:list

on the Karaf console to see, which zwave binding version you are exactly using. I doubt it’s the necessary newest one.

Is this the right way to wake-up the device (or let it send a NIF)? I thought it’s:

This is not a message from the device. It’s a message from the zwave controller. It must not even be related to the device (AFAIK).

chris · October 14, 2016, 12:47pm

That’s correct - it’s actually from the binding itself…

hermann59 · October 14, 2016, 1:32pm

Maybe. But I only have one zwave-device and everytime I turn the wheel this event is posted. Afterwards, PaperUI displays the node as “online”. If I don’t touch it, nothing happens. So in my opinion the device woke up.

hermann59 · October 14, 2016, 1:33pm

How do I get the karaf console ? My openhab2 is installed as a service.

chris · October 14, 2016, 1:42pm

Without looking at the logfile, you can’t be sure. All you can be reasonably sure of is the device sent something, but what it sent, you can’t say unless you have the log?

Wakeup is a specific message, and depending on the binding, what the device is sending, may or may not cause the binding to do something…

hermann59 · October 14, 2016, 2:41pm

@chris
I hope this is the correct line from “bundle:list”:
198 | Active | 80 | 2.0.0.201610131900 | ZWave Binding
Does it help?

jaydee73 · October 14, 2016, 2:45pm

All you need to know can be found in the documentation:

docs.openhab.org

shorty707 · October 14, 2016, 2:48pm

i can confirm the NIF is enough and works to get it configured
again: Single short click on micro button inside housing = NIF

@chris however the items of the device are not updated. probably because there is no Association Group for Lifeline in the DB?

hermann59 · October 14, 2016, 3:09pm

@chris
Which log? /var/log/openhab2/events.log ?

If I change the device configuration of my node in HABmin, I get the following log entries in event.log:
2016-10-14 17:02:36.273 [ThingUpdatedEvent ] - Thing ‘zwave:device:157be653371:node2’ has been updated.
2016-10-14 17:02:36.291 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
The only things I can change there is “Polling Period”, “Node Name” and “Node Location”. But the node is still an Unkown Device.

chris · October 14, 2016, 3:36pm

Yes - I think that in this version the NIF does not work as a wakeup (@shorty707 said it does, and it should, but this version probably doesn’t work)… So, you should use the latest version from today.

The “Lifeline” group is a new concept for ZWave. In ZWave plus, the lifeline is a requirement, and there are requirements on what should be reported, but in older devices there are no such requirements. I think this device is probably not ZWave plus (right?).

If I look in the database, there are NO association groups defined. There is also nothing in the manual, and in fact the supported classes doesn’t appear to include the association group…

The openhab.log file

shorty707 · October 14, 2016, 3:44pm

no its not - another thing I learned now

by this you mean …? currently the device was identified … but I could not get it really working

its communicating a little… like battery

however for setting temps or something I think I have to figure out what to do with
zwave_device_15348538564_node22_thermostat_mode

I will update here when I find some insights how to use it

hermann59 · October 14, 2016, 3:48pm

So probably the best would be to send the device back and choose a z-wave plus device?

chris · October 14, 2016, 3:56pm

I don’t know - I’d be surprised if it doesn’t support associations etc, but all the information seems to point to this fact! I’m not sure where it sends temperature reports for example - normally this is controlled through an association group, but here it can’t be. Maybe they are sent to the wakeup node - I don’t know.

I don’t say the device doesn’t work - just that I’m not sure how to configure it based on the information I see now…

Not necessarily. Many non ZWave plus devices already supported similar concepts, but just not in the ZWave plus defined way. They still use association groups, but maybe it’s group 2 or 3 and not the group 1 that is required by ZWave plus…

There are may good non-ZWave plus devices. Maybe this is one of them - if we can work our how it does its reporting ;).

hermann59 · October 14, 2016, 4:12pm

This is the node.xml:

    <node>

      <deviceClass>

        <basicDeviceClass>STATIC_CONTROLLER</basicDeviceClass>

        <genericDeviceClass>STATIC_CONTROLLER</genericDeviceClass>

        <specificDeviceClass>PC_CONTROLLER</specificDeviceClass>

      </deviceClass>

      <homeId>0xe0fdab7b</homeId>

      <nodeId>1</nodeId>

      <version>4</version>

      <manufacturer>0x115</manufacturer>

      <deviceId>0x1</deviceId>

      <deviceType>0x400</deviceType>

      <listening>true</listening>

      <frequentlyListening>false</frequentlyListening>

      <routing>false</routing>

      <security>false</security>

      <beaming>true</beaming>

      <maxBaudRate>40000</maxBaudRate>

      <supportedCommandClasses>

        <entry>

          <commandClass>BASIC</commandClass>

          <basicCommandClass>

            <version>0</version>

            <instances>0</instances>

            <versionSupported>0</versionSupported>

            <isGetSupported>true</isGetSupported>

          </basicCommandClass>

        </entry>

        <entry>

          <commandClass>NO_OPERATION</commandClass>

          <noOperationCommandClass>

            <version>1</version>

            <instances>0</instances>

            <versionSupported>1</versionSupported>

          </noOperationCommandClass>

        </entry>

      </supportedCommandClasses>

      <securedCommandClasses/>

      <associationGroups/>

      <nodeNeighbors>

        <int>2</int>

      </nodeNeighbors>

    </node>

Can I do something to help finding a solution?

chris · October 14, 2016, 4:17pm

I don’t think this is the correct XML. This looks like it’s for a ZWaveMe device, and probably from a controller…

shorty707 · October 14, 2016, 4:19pm

I tried to send updates for the Mode channel … according to the values defined in the DB

18:16:52.844 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'zwave_device_15348538564_node22_thermostat_mode' received command 11
18:16:52.851 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Command received zwave:device:15348538564:node22:thermostat_mode --> 11
18:16:52.852 [DEBUG] [lass.ZWaveThermostatModeCommandClass] - NODE 22: setValueMessage 11, modeType empty false
18:16:52.853 [DEBUG] [lass.ZWaveThermostatModeCommandClass] - NODE 22: Creating new message for application command THERMOSTAT_MODE_SET
18:16:52.855 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 22: Message already on the wake-up queue. Removing original.
18:16:52.856 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 22: Putting message SendData in wakeup queue.
18:16:52.873 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_device_15348538564_node22_thermostat_mode changed from 1 to 11
18:16:54.980 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'zwave_device_15348538564_node22_thermostat_mode' received command 31
18:16:55.103 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Command received zwave:device:15348538564:node22:thermostat_mode --> 31
18:16:55.105 [DEBUG] [lass.ZWaveThermostatModeCommandClass] - NODE 22: setValueMessage 31, modeType empty false
18:16:55.106 [DEBUG] [lass.ZWaveThermostatModeCommandClass] - NODE 22: Creating new message for application command THERMOSTAT_MODE_SET
18:16:55.107 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 22: Message already on the wake-up queue. Removing original.
18:16:55.108 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 22: Putting message SendData in wakeup queue.
18:16:55.125 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_device_15348538564_node22_thermostat_mode changed from 11 to 31

chris · October 14, 2016, 4:31pm

Looks fine to me - it’s a battery device, so it will go into the wakeup queue. What are you expecting to see?

shorty707 · October 14, 2016, 4:42pm

havent thought about that…so to set a temperature or a mode needs a wakeup… that would need a short wakeup interval when a manual setting of temperature shall be accepted fast