ZWAVE - New Thing: LS Control ES 861

Dear all,

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?

Thank you, best regards,
Bitty

There is a partial entry in the DB, but is missing the manual and a picture. Do you have a manual?
OpenSmartHouse Z-Wave Device Database

The blog describes how to register and get access to add the attachments.

Dear Bob,

thank you for your reply :-)!

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.

Best regards,
Bitty

I believe that is what derailed the last person to get this included. Z-Wave Database cannot create new device - Add-ons / Bindings - openHAB Community

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.

Last person checking in :slight_smile:

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.

Cheers :slight_smile:

1 Like

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.

I got some feedback from LS Control:

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.

How can I upload the documents here?

Here is the XML, hopefully the correct one :slight_smile:

<node>
  <homeId>0xc36146ab</homeId>
  <nodeId>17</nodeId>
  <version>2</version>
  <manufacturer>0x71</manufacturer>
  <deviceId>0x35d</deviceId>
  <deviceType>0x2</deviceType>
  <listening>false</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>false</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>500</sleepDelay>
  <nodeInformationFrame>
    <commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
    <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
    <commandClass>COMMAND_CLASS_WAKE_UP</commandClass>
    <commandClass>COMMAND_CLASS_BATTERY</commandClass>
    <commandClass>COMMAND_CLASS_VERSION</commandClass>
    <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
  </nodeInformationFrame>
  <associationGroups class="concurrent-hash-map"/>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_ROUTING_SLAVE</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_SENSOR_MULTILEVEL</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_ROUTING_SENSOR_MULTILEVEL</specificDeviceClass>
        </deviceClass>
        <endpointId>0</endpointId>
        <secureCommandClasses/>
        <supportedCommandClasses class="concurrent-hash-map">
          <entry>
            <commandClass>COMMAND_CLASS_NO_OPERATION</commandClass>
            <COMMAND__CLASS__NO__OPERATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_SENSOR_MULTILEVEL</commandClass>
            <COMMAND__CLASS__SENSOR__MULTILEVEL>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <sensors>
                <entry>
                  <multilevelSensorType>TEMPERATURE</multilevelSensorType>
                  <multilevelSensor>
                    <sensorType>TEMPERATURE</sensorType>
                    <initialised>true</initialised>
                  </multilevelSensor>
                </entry>
              </sensors>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__SENSOR__MULTILEVEL>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_CONFIGURATION</commandClass>
            <COMMAND__CLASS__CONFIGURATION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <configParameters/>
            </COMMAND__CLASS__CONFIGURATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_MANUFACTURER_SPECIFIC</commandClass>
            <COMMAND__CLASS__MANUFACTURER__SPECIFIC>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <initSerialNumber>false</initSerialNumber>
              <deviceManufacturer>113</deviceManufacturer>
              <deviceType>2</deviceType>
              <deviceId>861</deviceId>
            </COMMAND__CLASS__MANUFACTURER__SPECIFIC>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BATTERY</commandClass>
            <COMMAND__CLASS__BATTERY>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <batteryLevel>100</batteryLevel>
              <batteryLow>false</batteryLow>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BATTERY>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_WAKE_UP</commandClass>
            <COMMAND__CLASS__WAKE__UP>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <targetNodeId>1</targetNodeId>
              <interval>3600</interval>
              <minInterval>0</minInterval>
              <maxInterval>2147483647</maxInterval>
              <defaultInterval>0</defaultInterval>
              <intervalStep>0</intervalStep>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__WAKE__UP>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_ASSOCIATION</commandClass>
            <COMMAND__CLASS__ASSOCIATION>
              <version>0</version>
              <instances>0</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <maxGroups>0</maxGroups>
            </COMMAND__CLASS__ASSOCIATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_VERSION</commandClass>
            <COMMAND__CLASS__VERSION>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
              <libraryType>LIB_SLAVE_ENHANCED</libraryType>
              <protocolVersion>2.31</protocolVersion>
              <applicationVersion>3.10</applicationVersion>
            </COMMAND__CLASS__VERSION>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors>
    <int>1</int>
    <int>3</int>
    <int>4</int>
    <int>5</int>
    <int>6</int>
    <int>7</int>
    <int>8</int>
    <int>11</int>
    <int>12</int>
    <int>13</int>
    <int>15</int>
  </nodeNeighbors>
  <lastReceived>2024-01-10 05:04:54.87 UTC</lastReceived>
</node>

Not a surprising response (IMO).

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?

Thank you, Bob! After registration the site went down :joy: and I haven’t got the activation email. I will keep trying ;-).

Another question:

Do I have to do anything special or will the binding or the already included device update with the next OH update?

Thank you so much so far and in advance :slight_smile:
Bitty

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

From this site openHAB-ZWave [Jenkins]

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.

It is “live” in the snapshot referenced above via the bundle:update in Karaf console

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:

It’s been a couple of days and I’ve tried waking the device etc. Could it be something to do with the default params?

Since there is no manual, it is hard to say. If it is full initialized there will be 5 lines at the bottom of the device UI page.
Five Lines of configured node

If yes, I would suggest this

  1. Set the Zwave binding to debug. (far right side of settings page -may need to expand list)
  2. Hit the Reinitialise Device.
  3. Go to device to wake (need to wake until Reinitialise Device returns after page refresh)
    3A) Switch binding back to INFO
  4. Post log or use log viewer

Hopefully that will show something

Checked the DEBUG log output. Not sure what I’m looking for, but the only thing that looks a bit sus is this:

17:08:44.998 [DEBUG] [verter.ZWaveMultiLevelSensorConverter] - NODE 135: No sensorType set for channel zwave:device:z-stick:node135:sensor_temperature

The full output is really long so I placed it here

You are right about the Debug message.

Ok I think it see it. Item “Robin’s room” needs to be Number:temperature. Try that

Note in the debug 22.4 C is reported, so that is good.

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.

Interesting that the temperature briefly reported during setup.

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.

Best Regards,
Bitty