Zwave not assigning any thing types

  • Platform information:
    • Hardware: Raspberry Pi 4, 4G, 32G sim
    • Openhabian openhabian-pi-raspios32-202206272122-git852c09c-crced70fd0
    • Java Runtime Environment: Java build 11.0.15+10-post-Raspbian-1deb11u1
    • openHAB version: openhab 3, 32 bit, stable
    • HomeSeer Smartstick model SA-413-2
    • Mostly HomeSeer zwave switches, dimmers, and sensors. One zwave light bulb. Two TPLink switches. (I don’t have the mfgr of the zwave bulb to hand, I will have to find out in order to reset it or I will have to replace it.)

I had a running openhabian system until I (think I) blew out the SD card. I reinstalled a fresh openhabian, installed the bindings, and tried to discover my stuff. I had done this successfully two or three times before. The zwave binding found and recognized the Smartstick and then found and quickly recognized all the zwave devices.

This time it found the Smartstick and it detected all the zwave devices but did not find the Thing type for any of them. I thought at first it was a problem with HomeSeer things but it did not recognize the zwave bulb either. I don’t know whether the binding is querying the switches etc. and not getting the mfgr ID etc. or if it is not querying at all.

I have tried:

  • Waiting for a couple days
  • Deleting and rediscovering the thing
  • Deleting all the things, deleting the Smartstick, rediscovering the Smartstick, and rediscovering the things
  • Deleting all the things, removing the binding, reinstalling the binding, and you know.
  • Another fresh reinstall
  • Deleting all the things and hard resetting the Smartsitck!
  • Trying my spare Smartstick

I’ll bet that there is something blindingly simple that I am missing. Any ideas?

All of my HomeSeer are in the zwave database as it is listed here:
https://www.openhab.org/addons/bindings/zwave/doc/things.html

XML for the Smartstick:

<node>
  <homeId>0xe9339c59</homeId>
  <nodeId>1</nodeId>
  <version>4</version>
  <manufacturer>0x0</manufacturer>
  <deviceId>0x8</deviceId>
  <deviceType>0x3</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>500</sleepDelay>
  <associationGroups class="concurrent-hash-map"/>
  <endpoints class="concurrent-hash-map">
    <entry>
      <int>0</int>
      <endPoint>
        <deviceClass>
          <basicDeviceClass>BASIC_TYPE_STATIC_CONTROLLER</basicDeviceClass>
          <genericDeviceClass>GENERIC_TYPE_STATIC_CONTROLLER</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_PC_CONTROLLER</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>0</instances>
              <control>false</control>
              <versionSupported>1</versionSupported>
            </COMMAND__CLASS__NO__OPERATION>
          </entry>
          <entry>
            <commandClass>COMMAND_CLASS_BASIC</commandClass>
            <COMMAND__CLASS__BASIC>
              <version>0</version>
              <instances>0</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors>
    <int>3</int>
    <int>6</int>
    <int>7</int>
    <int>8</int>
    <int>10</int>
    <int>11</int>
    <int>12</int>
    <int>13</int>
    <int>15</int>
    <int>16</int>
    <int>17</int>
    <int>18</int>
    <int>19</int>
    <int>21</int>
    <int>23</int>
    <int>24</int>
    <int>25</int>
    <int>26</int>
    <int>27</int>
    <int>31</int>
  </nodeNeighbors>

XML for a representative HS_WD200+ dimmer:

<node>
  <homeId>0xe9339c59</homeId>
  <nodeId>3</nodeId>
  <version>4</version>
  <manufacturer>0x7fffffff</manufacturer>
  <deviceId>0x7fffffff</deviceId>
  <deviceType>0x7fffffff</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <sleepDelay>500</sleepDelay>
  <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_SWITCH_MULTILEVEL</genericDeviceClass>
          <specificDeviceClass>SPECIFIC_TYPE_POWER_SWITCH_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>0</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>0</versionSupported>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__BASIC>
          </entry>
        </supportedCommandClasses>
      </endPoint>
    </entry>
  </endpoints>
  <nodeNeighbors/>

You need to answer this question.

My guess is that there is some sort of communication issue with the devices, but really we can only guess without more information. I would suggest to enable debug logging on the binding and see what that shows. This is described in the binding docs.

Thank you very much for your help. I’m going to try that now. I assume that there is at least SOME communication going on because the things are discovered.

The list of discovered devices comes from the stick and doesn’t necessarily mean there is communication with the device.

Besides the Debug which as @chris notes is needed for analysis, and this could just be language, but when you say “delete” do you mean the “Delete Thing” on the UI page for the device or did you use the “exclude Devices” on the Controller UI page and perform the Exclude protocol from the device manual. Only the “Exclude Devices” truly resets the device to an “Unpaired” state, so that it can be scanned and rediscovered (with a new Node number). Everything works best with an unpaired (or factory reset) node and a Z-stick with no remnants of previous inclusions.

Good luck and welcome to OpenHab

Bob

Yes, I used Delete Thing. When I hard reset the z-stick I also deleted and rediscovered it so it ended up with a new ID. I noticed that I got new xml for the things I included because of the new id.

If I were to do it again, I would use Exclude Devices. Now I have to go around and reset every switch, dimmer, sensor and net extender. Who knows WHAT I’m going to do with that poor orphaned light bulb!

You can still exclude the devices if that’s easier - even though you’ve reset the stick. Using the exclude option, and then pressing whatever button on the device will also exclude/reset the device even if it is not part of the controllers network.

There is definitely no successful communication going on between the binding and the things. I am really out of my depth here. I am a software guy. Hardware is magic to me.

openhab.log (532.2 KB)

Again, thank you, both of you.

Have you flashed new firmware to your stick (or replaced the stick)? It looks like it’s now in a different mode (bridge mode).

The devices are communicating (nodes 3 and 4 at least), but the controller is sending the responses back to the binding in a way the binding doesn’t understand so it ignores them.

I’m going to switch back to the other stick that I know used to work. I have no reason to believe that it doesn’t work.

Is it save to delete the unused xml files in the zwave directory?

The stick is set as Master and the SIS Node setting is 1, which is its own node number. That is how it was set up when discovered. That is correct?

I hadn’t picked up on the fact that you had changed sticks, so this is likely the root cause - the new stick is a bridge controller.

Yes, that’s fine.

That’s fine. I assume you’re now using the original stick?

I’ve just discovered the old stick. The new stick is model SA370-2. I assumed that they are the same model.

The new stick can’t be THE reason. I changed sticks as a last try to get it working.

The new stick is the reason the binding can’t communicate with the devices.

As above, the devices are communicating, but the stick is sending the data back to the binding using different commands that the binding is ignoring. This is due to the firmware in the stick.

I have reached critical frustration level. Now with the old stick, I can’t get any of the switches to join.

I am going to have to step away from this so I won’t do something stupid(er). I have a feeling that all the switching and resetting has left things screwed up. I’m going to do yet another fresh install and check back in with you when I am done.

Thank you.

Oh, and the old stick is identified as a BRIDGE on the scan-for-things page. I am 93.7% sure that it always was.

Yes, but this is not what I’m talking about though when I say that the new stick has a bridge firmware. Here you are talking about an openHAB bridge Thing - a bridge in OH is a thing that allows other things to be connected.

I am talking about the firmware in the stick - there are a few types of firmware - one is bridge firmware, and another is static controller firmware - they work differently and the bridge firmware is not compatible - you need the static controller firmware.

Chris, I have just ordered an Aetec Z-Stick Gen 5+ which should arrive Wednesday. I went with a Homeseer stick because I have much Homeseer stuff in my house. I thought the Homeseer things would be happier with a Homeseer stick. I think that that was a bad choice.

I hope to be able to report that all is good on Wednesday.

Another option down the road might be to consider flashing new firmware on your older sticks. The USB programing software is described here. This article was to update an Aeotec Zstick, but I have used a similar (or same) Silabs app to create a Zniffer from a 500 chip controller. There is also firmware for both bridge and static controllers with Silabs.

Bob

Thank you Chris and all The problem was the z-stick. I replaced the old stick with an Aeotec Z-Stick Gen5+ and it recognized the dimmer BANG right off the bat. Never had that kind of responsiveness from the HomeSeer stick.

I am tempted to flash the firmware on my two HomeSeer sticks just to sere if it would make a difference. I probably won’t, who has time?

Thank you very much for a very useful binding. The toys in my house would not be possible without it.