ZWAVE - New Thing: LS Control ES 861

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

The latest snapshot has the fix (hopefully- do not know if the xml above was tested as working) to the problem identified by @AlexMartin13.

I didn’t find the time to try the .xml file manually, but updating to the snapshot binding worked a charm! Thanks for all your help @apella12

After that success, unfortunately I needed to reinstall openHAB for unrelated reasons. In doing so I forgot the URI needed to update the zwave binding to the latest snapshot using the bundle:update approach. After reading the docs and forums, I tried using the following URI:

bundle:update 280 https://openhab.jfrog.io/artifactory/sandbox-snapshot/org/openhab/addons/bundles/org.openhab.binding.zwave/4.1.2-SNAPSHOT/org.openhab.binding.zwave-4.1.2-20240105.154215-12.jar

And it looks like it’s updated okay:
280 │ Active │ 80 │ 4.1.2.202401051542 │ openHAB Add-ons :: Bundles :: ZWave Binding

However, the device is still unrecognised even after waking, reinitilaising and re-adding.
This is what I see in the console when waking the device:

17:43:29.229 [WARN ] [zwave.discovery.ZWaveDiscoveryService] - NODE 135: Device discovery could not resolve to a thingType! 0071:0002:035D::3.10
17:43:30.121 [INFO ] [commandclass.ZWaveVersionCommandClass] - NODE 135: Command Class COMMAND_CLASS_ASSOCIATION has version 0!

Is this the correct version of the binding?

no. You will need a 4.2 snapshot. I posted the site above (#9) on jan 18