I bought a temperature and humidity sensor LS Control ES 861.
I included the device into an existing zwave network via opehab but the problem is that the z-wave binding in openhab does not cover any channels. The thing type is unknown.
As far as I understood the following information say that the device is not covered by the binding, isn’t it?
Following the details from “thing type” and “thing properties”
This device has not been fully discovered by the binding. There are a few possible reasons for this -:
The device is not in the database. If the device attributes show that this device has a valid manufacturer ID, device ID and type, then this is likely the case (eg. you see a label like “Z-Wave node 1 (0082:6015:020D::2.0)”). Even if the device appears to be in the database, some manufacturers use multiple sets of references for different regions or versions, and your device references may not be in the database. In either case, the database must be updated and you should raise an issue to get this addressed.
The device initialisation is not complete. Once the device is included into the network, the binding must interrogate it to find out what type of device it is. One part of this process is to get the manufacturer information required to identify the device, and until this is done, the device will remain unknown. For mains powered devices, this will occur quickly, however for battery devices the device must be woken up a number of times to allow the discovery phase to complete. This must be performed with the device close to the controller.
Thing Properties
16
zwave_deviceid
861
zwave_routing
true
zwave_class_basic
BASIC_TYPE_ROUTING_SLAVE
zwave_frequent
false
zwave_listening
false
zwave_version
3.10
zwave_lastheal
2024-01-03T02:30:35Z
zwave_nodeid
17
zwave_beaming
false
zwave_class_specific
SPECIFIC_TYPE_ROUTING_SENSOR_MULTILEVEL
zwave_class_generic
GENERIC_TYPE_SENSOR_MULTILEVEL
zwave_secure
false
zwave_neighbours
1,3,4,5,6,7,12,13,15
zwave_lastwakeup
2024-01-03T13:45:18Z
zwave_manufacturer
113
zwave_devicetype
2
What can one (me?) do so that the device is working?
Unfortunately, I don’t have the manual. I didn’t get it from the shop (vesternet) and I haven’t got answer from LS Control so far (in the website the product is not listed anymore).
Your link shows only the “E” version, I have the “ES” version and it should be able to measure temperature und humidity. (Update: the zwave_manufacturer is different)
I think this is another link to more information about the device: products.z-wavealliance.org/products/315?selectedFrequencyId=1
A picture is on the linked website but I could also make some pictures.
Do you have a Node17 XML in the userdata/zwave folder? What does that look like
As all the links appear broken, what I think; LS Control made these devices for awhile and then stopped and sold all the stock to resellers with no manual and no support. IMO these look clunky and there are better humidity and temperature devices out there.
Sorry to say that my solution was to use something other than openHAB.
I now have eight of these sensors running in our house. No disconnections or other issues. At £10 each I reckon they’re just a loss leader as I got a Aeotec Z-Stick Gen5+ USB Controller at the same time. Note that they don’t transmit any humidity values, only temperature.
Unfortunately the database entry wasn’t deleted. I did ask for that in my last post. That was the blocker for me, so perhaps making more noise than I did might get it removed and give you the chance to make progress.
Could be some miscommunication on my part. The plan was to undelete and then modify the existing entry. It was basically aligned with the XML you posted, so only a couple of references needed to be added.
Anyway to resolve I added some references and marked for review. Should be in next ZW update.
@Bitty If you found your XML, please post for double check.
Thank you for your e-mail. I have talked with our technical support regarding your inquiry.
Unfortunately the product is very old and never really penetrated the market. Hence it is not fully supported for newer protocols. Some newer protocols are even known to drain the batteries in 48hours on these, because the ES 861 answers every ping.
Please see this Danish short document for the Temperature sensor and a long one for a different version with a potentiometer, but should be the same communication.
That’s all the documentation we can provide for this sensor.
The product went out of production in February 2017.
Your XML is the same as the one already in the ZW DB. I was just curious if the humidity might be displayed under SENSOR__MULTILEVEL, but it is not.
Actually, to resolve this issue I went ahead and copied some information from the ZWA site and finished the DB entry and marked for review. If it passes review it should be in the next ZW binding snapshot without any additional effort. However you can follow the blog, register, open ticket for write access & once granted, add the documents to the reference tab. Hopefully they are in english?
It will be in the daily snapshot update. If you are on 4.1.0 or 4.1.1 you should be able to just update your binding per the docs. Bundle Management | openHAB
Weirdly, I just bought one from Vesternet and have come looking on the forum so see why it’s not working. They really should slap a warning on the product page if the device is unlikely to work with most systems.
Let me know if the new binding goes live and I’ll test an update also.
Progress! I’ve updated and it has now been recognised. Looking through the Thing definition suggests it has fully initialised; all of the details and parameters seems to be present.
The battery channel is reporting correctly but unfortunately the Temperature channel state remains as NULL:
I may have misinterpreted your suggestion but I tried changing Number:Temperature to Number:temperature and received this message:
09:42:15.855 [INFO ] [del.core.internal.ModelRepositoryImpl] - Loading model 'zwave.items'
09:42:15.918 [INFO ] [del.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'zwave.items', using it anyway:
'temperature' is not a valid dimension.
According to the item documentation it should include the capitalisation, but again I may have misunderstood.
I define my items textually, but as a test I created the channel through openHAB UI. By default the item is added as Number.Temperature•Point. However, the result is the same.
Further investigation suggests that there is something awry with the channel config parameter in zwave items db for the LSControl Temperature Sensor. Similar to this issue
You can see the point of failure when comparing the DEBUG output for the (working) Battery channel to the Temperature channel:
17:08:44.782 [DEBUG] [otocol.commandclass.ZWaveCommandClass] - NODE 135: Received COMMAND_CLASS_BATTERY V1 BATTERY_REPORT
17:08:44.786 [DEBUG] [commandclass.ZWaveBatteryCommandClass] - NODE 135: Battery report value = 100
17:08:44.789 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 135: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
17:08:44.793 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 135: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BATTERY, value=100
17:08:44.797 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 135: Updating channel state zwave:device:z-stick:node135:battery-level to 100 [DecimalType]
17:08:44.803 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 135: Commands processed 1.
17:08:44.981 [DEBUG] [otocol.commandclass.ZWaveCommandClass] - NODE 135: Received COMMAND_CLASS_SENSOR_MULTILEVEL V1 SENSOR_MULTILEVEL_REPORT
17:08:44.984 [DEBUG] [ass.ZWaveMultiLevelSensorCommandClass] - NODE 135: Adding new sensor Type = Temperature(1)
17:08:44.987 [DEBUG] [ass.ZWaveMultiLevelSensorCommandClass] - NODE 135: Sensor Type = Temperature(1), Scale = 0
17:08:44.989 [DEBUG] [ass.ZWaveMultiLevelSensorCommandClass] - NODE 135: Sensor Value = 22.4
17:08:44.992 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 135: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
17:08:44.995 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 135: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=22.4
17:08:44.998 [DEBUG] [verter.ZWaveMultiLevelSensorConverter] - NODE 135: No sensorType set for channel zwave:device:z-stick:node135:sensor_temperature
17:08:45.001 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 135: Commands processed 1.
Note in particular:
17:08:44.998 [DEBUG] [verter.ZWaveMultiLevelSensorConverter] - NODE 135: No sensorType set for channel zwave:device:z-stick:node135:sensor_temperature
So presumably there is no way to manually resolve this and it needs to be updated in the database?
I think you are correct about this. I made the change and marked for review. Thanks for finding it.
As workaround/confirmation (while waiting for a new DB merge) this is a marked up XML that could be changed in your current binding using the procedure here (folder=lscontrol) es861c_0_0.xml (3.6 KB)
Finally, I got permission to upload the documents. You find it under “reference”.
It’s great to see how it works with a new device and that it’s already working for some of us with manual adjustments. I will probably wait for a “normal” update of the binding.