Fibaro FGBS001 Universal Binary Sensor not working in openHAB2

[sihui]

Sorry, took a little while, had a system breakdown after first start with new build #619

Yes, it’s a switch:

sitemap:

Switch item=TestBinarySensor1
Switch item=TestBinarySensor2
Switch item=TestGeneralAlarm1
Switch item=TestGeneralAlarm2

debug log while triggering both inputs:

https://gist.github.com/sihui62/8557c873c4348a24d05cca1f37b75934

events.log while triggering both inputs:

2016-11-27 21:57:28.714 [ItemStateChangedEvent     ] - Barometer changed from 1027.257 to 1027.266
2016-11-27 21:58:00.080 [ItemCommandEvent          ] - Item 'Licht_UG_Fountain' received command OFF
2016-11-27 21:58:28.773 [ItemStateChangedEvent     ] - Barometer changed from 1027.266 to 1027.277
2016-11-27 21:59:24.889 [ItemStateChangedEvent     ] - FibEye1_Motion_S changed from OFF to ON

Shortly before that I got massive data from node 21:

https://gist.github.com/sihui62/3cb767ab4ba2ec1e29352bb3b15bb6ce

[Stefanseiner]

I’m using this sensor too and got some of problems with it.
While two days ago the sensors worked fine (I’m using 5 of them) now I have the 3rd one which won’t send some or any information.

Maybe first my config which is working:

• OH2 1 week old nightly snapshot (don’t know exactly the day and version and don’t know how to check the version)
• Z-wave binding: binding-zwave - 2.0.0.SNAPSHOT

here my .items:

	/* Auge */
	Number Flur_Auge_Lux 		{channel="zwave:device:5b97d7f6:node6:sensor_luminance"}
	Number Flur_Auge_Battery 	{channel="zwave:device:5b97d7f6:node6:battery-level"}
	Number Flur_Auge_Temp 		{channel="zwave:device:5b97d7f6:node6:sensor_temperature"}
	Switch Flur_Auge_Binary 	{channel="zwave:device:5b97d7f6:node6:sensor_binary"} 
	Switch Flur_Auge_Alarm 		{channel="zwave:device:5b97d7f6:node6:alarm_general"}
	Number Flur_Auge_Seismic 	{channel="zwave:device:5b97d7f6:node6:sensor_seismicintensity"}
	Switch Flur_Auge_Burglar 	{channel="zwave:device:5b97d7f6:node6:alarm_burglar"}

Actually I used successfully the lux, battery and temp values,
and for light-on-when-movement I used the burglar alarm.

Here some screenshots of PaperUI and Habmin
[URL=http://www.imagebam.com/image/6d0013517047493][/URL]

[URL=http://www.imagebam.com/image/fe7ef9517047511][/URL]

[URL=http://www.imagebam.com/image/ad3db0517047526][/URL]

[URL=http://www.imagebam.com/image/5e3ac6517047555][/URL]

[URL=http://www.imagebam.com/image/4fde28517047595][/URL]

As I wrote: all went fine. Besides of that one of the eyes did’t show some values (lux and temp) so I began excluding and re-including.
I did this two times or so because I’ve read that some people just included the eyes with success while doing this several times.
But then: the burglar alarm didn’t work anymore. I testet several times, excluding and reincluding but nothing, burglar alarm seems to be dead. So I guessed it’s a defect and yesterday I wrote to the seller for an refund.

But today I made some more testings with the oder eyes and now - two more lost the burglar alarm.
I have no idea why but the two left which are running well aren’t excluded and included several times, they just working.

Is there any function in OH zu reset all the z-wave settings and configs?
I just deleted the node .xml files but this didn’t any affect (searching for new devices at PaperUI still shows the eye which is already packed for refund without battery…)

[sihui]

@Stefanseiner

I’m using this sensor too

In this thread we are talking about the FGBS001, the Fibaro Universal Binary Sensor:

I’m sure Chris will come back to both of our problem threads as soon as he has some time available.

"Error: 404 - Not Found" when updating Fibaro FGMS001 at PaperUI

Hello, since today I get error message when editing one of the Fibaro FGMS001 multi sensors at PaperUI. Error occurs just with the FGMS, no matter which option I try to change and no matter which of the FGMS sensors. I can edit my milight bulby without any problems. Here’s the log: 19:57:57.716 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while calling thing updated at ThingHandler 'org.openhab.binding.zwave.handler.ZWaveThingHandler@8dc8de: java.lang.NullPointerExcept…

[Stefanseiner]

@sihui

In this thread we are talking about the FGBS001

Oh. Sorry, my mistake

[chris (Chris Jackson)]

@sihui

debug log while triggering both inputs:

Strange - this is not using multi-channel encapsulation -:

There is no channel associated with the root endpoint…

@sihui

Shortly before that I got massive data from node 21:

That was part of the initialisation. During init the binding did request the two endpoints -:

During this initialisation it should have updated the channel - eg -:

2016-11-27 21:52:37.730 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Updating channel state zwave:device:1587db82cfc:node21:sensor_binary2 to ON [OnOffType]

So, I don’t know how to solve this. If the device doesn’t send the two different inputs with some way to tell them apart (ie using multi-channel) then I don’t know how we can process it. Maybe there’s a setting, or maybe it requires the multi-channel-association to trigger multi-channel messages (some new devices do this, but I’ve not seen it in any Fibaro devices yet).

[sihui]

@chris

Maybe there’s a setting

I booted up my old openHAB1 system and the device works as expected.
While doing that I realized a difference in the number of association groups:

in openHAB1 we have three associations groups, “Controller updates” need to be set to the controller:

In openHAB2 we only have two associations groups:

and there is still a message in the database which I cannot understand:

Could this be a point where we can make the device work under openHAB2?
Btw, meanwhile I can see (in openHAB2) the switches on the sitemap changing their state according to the input, but still nothing in the event.log.

[chris (Chris Jackson)]

@sihui

and there is still a message in the database which I cannot understand:

This simply means that none of the groups have the ‘controller’ box ticked. This means that the binding won’t automatically configure the device to send messages to the controller…

It looks like the missing link might be group 3… Do you want to add it?

@sihui

I can see (in openHAB2) the switches on the sitemap changing their state according to the input, but still nothing in the event.log

Well, that’s strange. I very rarely look at the event log, but if the items are changing state (as seen in the sitemap) then I’ve no idea why the event log wouldn’t log the change. It’s outside of the binding though - the binding just sends channel updates - the framework updates the items…

[sihui]

@chris

Do you want to add it?

I’ve just done that manually. Or is it better to upload a “fresh” xml file? Before we started changing the entries for this device it had not been touched for about six month.
Also the device is able to send scene numbers for the scene activation command class which isn’t reflected in the database yet.

<node>
  <deviceClass>
    <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
    <genericDeviceClass>BINARY_SENSOR</genericDeviceClass>
    <specificDeviceClass>ROUTING_SENSOR_BINARY</specificDeviceClass>
  </deviceClass>
  <homeId>0xc239030a</homeId>
  <nodeId>22</nodeId>
  <version>4</version>
  <manufacturer>0x10f</manufacturer>
  <deviceId>0x1002</deviceId>
  <deviceType>0x501</deviceType>
  <listening>true</listening>
  <frequentlyListening>false</frequentlyListening>
  <routing>true</routing>
  <security>false</security>
  <beaming>true</beaming>
  <maxBaudRate>40000</maxBaudRate>
  <nodeInformationFrame>
    <commandClass>SENSOR_BINARY</commandClass>
    <commandClass>MULTI_INSTANCE</commandClass>
    <commandClass>ASSOCIATION</commandClass>
    <commandClass>MULTI_INSTANCE_ASSOCIATION</commandClass>
    <commandClass>MANUFACTURER_SPECIFIC</commandClass>
    <commandClass>CONFIGURATION</commandClass>
    <commandClass>VERSION</commandClass>
    <commandClass>FIRMWARE_UPDATE_MD</commandClass>
  </nodeInformationFrame>
  <supportedCommandClasses>
    <entry>
      <commandClass>CONFIGURATION</commandClass>
      <configurationCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <configParameters>
          <entry>
            <int>1</int>
            <configurationParameter>
              <index>1</index>
              <size>2</size>
              <value>0</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>2</int>
            <configurationParameter>
              <index>2</index>
              <size>2</size>
              <value>0</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>3</int>
            <configurationParameter>
              <index>3</index>
              <size>1</size>
              <value>1</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>4</int>
            <configurationParameter>
              <index>4</index>
              <size>1</size>
              <value>1</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>5</int>
            <configurationParameter>
              <index>5</index>
              <size>1</size>
              <value>-1</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>6</int>
            <configurationParameter>
              <index>6</index>
              <size>1</size>
              <value>-1</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>7</int>
            <configurationParameter>
              <index>7</index>
              <size>1</size>
              <value>-1</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>8</int>
            <configurationParameter>
              <index>8</index>
              <size>1</size>
              <value>-1</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>9</int>
            <configurationParameter>
              <index>9</index>
              <size>1</size>
              <value>0</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>10</int>
            <configurationParameter>
              <index>10</index>
              <size>1</size>
              <value>20</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>11</int>
            <configurationParameter>
              <index>11</index>
              <size>1</size>
              <value>-56</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>12</int>
            <configurationParameter>
              <index>12</index>
              <size>1</size>
              <value>8</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>13</int>
            <configurationParameter>
              <index>13</index>
              <size>1</size>
              <value>0</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
          <entry>
            <int>14</int>
            <configurationParameter>
              <index>14</index>
              <size>1</size>
              <value>0</value>
              <readOnly>false</readOnly>
              <writeOnly>false</writeOnly>
            </configurationParameter>
          </entry>
        </configParameters>
      </configurationCommandClass>
    </entry>
    <entry>
      <commandClass>MULTI_INSTANCE_ASSOCIATION</commandClass>
      <multiAssociationCommandClass>
        <version>2</version>
        <instances>1</instances>
        <versionSupported>2</versionSupported>
        <maxGroups>2</maxGroups>
      </multiAssociationCommandClass>
    </entry>
    <entry>
      <commandClass>VERSION</commandClass>
      <versionCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <libraryType>LIB_SLAVE_ENHANCED</libraryType>
        <protocolVersion>3.52</protocolVersion>
        <applicationVersion>2.1</applicationVersion>
      </versionCommandClass>
    </entry>
    <entry>
      <commandClass>MANUFACTURER_SPECIFIC</commandClass>
      <manufacturerSpecificCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <initSerialNumber>false</initSerialNumber>
        <deviceManufacturer>271</deviceManufacturer>
        <deviceType>1281</deviceType>
        <deviceId>4098</deviceId>
      </manufacturerSpecificCommandClass>
    </entry>
    <entry>
      <commandClass>FIRMWARE_UPDATE_MD</commandClass>
      <firmwareUpdateCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
      </firmwareUpdateCommandClass>
    </entry>
    <entry>
      <commandClass>NO_OPERATION</commandClass>
      <noOperationCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
      </noOperationCommandClass>
    </entry>
    <entry>
      <commandClass>SENSOR_BINARY</commandClass>
      <binarySensorCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <isGetSupported>true</isGetSupported>
        <types/>
      </binarySensorCommandClass>
    </entry>
    <entry>
      <commandClass>ASSOCIATION</commandClass>
      <associationCommandClass>
        <version>2</version>
        <instances>1</instances>
        <versionSupported>2</versionSupported>
        <maxGroups>3</maxGroups>
      </associationCommandClass>
    </entry>
    <entry>
      <commandClass>BASIC</commandClass>
      <basicCommandClass>
        <version>1</version>
        <instances>1</instances>
        <versionSupported>1</versionSupported>
        <isGetSupported>true</isGetSupported>
      </basicCommandClass>
    </entry>
    <entry>
      <commandClass>MULTI_INSTANCE</commandClass>
      <multiInstanceCommandClass>
        <version>2</version>
        <instances>1</instances>
        <versionSupported>2</versionSupported>
        <endpoints>
          <entry>
            <int>1</int>
            <endPoint>
              <deviceClass>
                <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
                <genericDeviceClass>BINARY_SENSOR</genericDeviceClass>
                <specificDeviceClass>ROUTING_SENSOR_BINARY</specificDeviceClass>
              </deviceClass>
              <endpointId>1</endpointId>
              <supportedCommandClasses>
                <entry>
                  <commandClass>SENSOR_ALARM</commandClass>
                  <alarmSensorCommandClass>
                    <endpoint reference="../../../.."/>
                    <version>0</version>
                    <instances>1</instances>
                    <versionSupported>0</versionSupported>
                    <alarms/>
                    <isGetSupported>true</isGetSupported>
                    <isSupportedGetSupported>false</isSupportedGetSupported>
                  </alarmSensorCommandClass>
                </entry>
                <entry>
                  <commandClass>SENSOR_BINARY</commandClass>
                  <binarySensorCommandClass>
                    <endpoint reference="../../../.."/>
                    <version>1</version>
                    <instances>1</instances>
                    <versionSupported>1</versionSupported>
                    <isGetSupported>true</isGetSupported>
                    <types/>
                  </binarySensorCommandClass>
                </entry>
                <entry>
                  <commandClass>BASIC</commandClass>
                  <basicCommandClass>
                    <endpoint reference="../../../.."/>
                    <version>0</version>
                    <instances>0</instances>
                    <versionSupported>0</versionSupported>
                    <isGetSupported>true</isGetSupported>
                  </basicCommandClass>
                </entry>
              </supportedCommandClasses>
            </endPoint>
          </entry>
          <entry>
            <int>2</int>
            <endPoint>
              <deviceClass>
                <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>
                <genericDeviceClass>BINARY_SENSOR</genericDeviceClass>
                <specificDeviceClass>ROUTING_SENSOR_BINARY</specificDeviceClass>
              </deviceClass>
              <endpointId>2</endpointId>
              <supportedCommandClasses>
                <entry>
                  <commandClass>SENSOR_ALARM</commandClass>
                  <alarmSensorCommandClass>
                    <endpoint reference="../../../.."/>
                    <version>0</version>
                    <instances>1</instances>
                    <versionSupported>0</versionSupported>
                    <alarms/>
                    <isGetSupported>true</isGetSupported>
                    <isSupportedGetSupported>false</isSupportedGetSupported>
                  </alarmSensorCommandClass>
                </entry>
                <entry>
                  <commandClass>SENSOR_BINARY</commandClass>
                  <binarySensorCommandClass>
                    <endpoint reference="../../../.."/>
                    <version>1</version>
                    <instances>1</instances>
                    <versionSupported>1</versionSupported>
                    <isGetSupported>true</isGetSupported>
                    <types/>
                  </binarySensorCommandClass>
                </entry>
                <entry>
                  <commandClass>BASIC</commandClass>
                  <basicCommandClass>
                    <endpoint reference="../../../.."/>
                    <version>0</version>
                    <instances>0</instances>
                    <versionSupported>0</versionSupported>
                    <isGetSupported>true</isGetSupported>
                  </basicCommandClass>
                </entry>
              </supportedCommandClasses>
            </endPoint>
          </entry>
        </endpoints>
        <useDestEndpointAsSource>false</useDestEndpointAsSource>
        <endpointsAreTheSameDeviceClass>true</endpointsAreTheSameDeviceClass>
      </multiInstanceCommandClass>
    </entry>
  </supportedCommandClasses>
  <securedCommandClasses/>
  <associationGroups>
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>
  <nodeNeighbors>
    <int>1</int>
    <int>4</int>
    <int>10</int>
    <int>11</int>
    <int>13</int>
  </nodeNeighbors>
  <lastSent>2016-12-04 11:53:03.265 UTC</lastSent>
  <lastReceived>2016-12-04 11:53:07.662 UTC</lastReceived>
</node>

[chris (Chris Jackson)]

@sihui

I’ve just done that manually. Or is it better to upload a “fresh” xml file?

Manual is fine - uploading a new XML won’t work - the database ignores XMLs once there’s a certain amount of configuration done to avoid someone loading the wrong file and making a mess ;).

Feel free to add the scene class(es) if you want?

[sihui]

@chris

Feel free to add the scene class(es) if you want?

Done.

@chris

and making a mess

Hopefully that’s not what I’m doing now with the manual changes

[chris (Chris Jackson)]

Thanks - looks ok I think (from the quick look I had of the changes email). I’ll update the binding this evening.

[sihui]

Short story:
The device is working, thanks a lot for your support!!!

I have a warning in the logs

2016-12-10 08:04:08.920 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 23: CommandClass BASIC (0x20) not implemented by endpoint 1, fallback to main node.
2016-12-10 08:04:14.122 [WARN ] [class.ZWaveMultiInstanceCommandClass] - NODE 23: CommandClass BASIC (0x20) not implemented by endpoint 2, fallback to main node.

but actually I don’t care because it’s working without any problems

Newly added scene numbers are also working as expected:

2016-12-07 08:42:52.484 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 21 to 10
2016-12-07 08:42:54.018 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 10 to 11
2016-12-07 08:44:10.132 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 11 to 20
2016-12-07 08:44:10.387 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 20 to 21

If anybody is interested you can find more information about scene numbers here:
http://manuals.fibaro.com/binary-sensor/ (scroll down to “Parameter 14”)

Textual items configuration can be done via:

Number FibUniSens1_0	"FibUniSensEP0 [%s]"	{channel="zwave:device:158b44ebf65:node23:scene_number"}
Switch FibUniSens1_1	"FibUniSensEP1 [%s]"	{channel="zwave:device:158b44ebf65:node23:sensor_binary1"}
Switch FibUniSens1_2	"FibUniSensEP2 [%s]"	{channel="zwave:device:158b44ebf65:node23:sensor_binary2"}

Long story:
as I stated earlier I bought a new device because after migrating to openHAB2 I couldn’t get it to work (and because I had accidentally switched the power plus and minus for a few seconds I thought it is broken).

Most of the testing in this thread was done with this new device … and after a couple of days it turned out that the NEW device is not functioning properly (will get a free replacement today).

As soon as I switched back to the old device everything started working … so I cannot tell which of the database changes made the device working.

Thanks again for your neverending support on this binding

[chris (Chris Jackson)]

Glad it’s working…

@sihui

I have a warning in the logs

Just to be clear, you’re running a recent version and have deleted and re-added the thing since we made the changes to the DB? This was one of the changes I made to the database so I wouldn’t have expected these errors…

If you can provide the debug log showing the frame received it might be useful as I don’t think this warning should be occurring.

[sihui]

@chris

Just to be clear, you’re running a recent version and have deleted and re-added the thing since we made the changes to the DB?

openHAB2 version # 631, zwave binding 2.0.0.201612051634 and yes, deleted thing and re-added.

@chris

debug log

for EP1:
https://gist.github.com/sihui62/0ba04ac24348ba69707642915916a7db

[chris (Chris Jackson)]

Can you also post the XML. I’m guessing it’s probably the same as the previous ones, but since you said you changed to an older version I just want to check. The XMLs above show that the binding has the BASIC class in these endpoints, so I’d expect this to work

[sihui]

@chris

post the XML

https://gist.github.com/sihui62/aaadb6ed517240066aaf2cba7480338a

[chris (Chris Jackson)]

Hmmm - thanks. For some reason then, this version of the XML doesn’t show the BASIC class in the endpoints. This explains why there’s an error, but why is it different to the previous versions of the XMLs you posted here ?!?!?

If you don’t mind, can you delete the XML and get a log of this device during startup (ie a complete log of the initialisation).

I’m handling this a bit different in the new version, so this won’t be a problem, but just interested to see what’s happening if you don’t mind. If you’re happy to leave this, then it should go away in future anyway…

[sihui]

@chris

If you don’t mind, can you delete the XML

Sure, no problem at all.

https://gist.github.com/sihui62/9c4f5b25211c3d867b5ba28608356fa8

openHAB2 is still a beta snapshot, so we should all be willing to test it as much we can (although I must admit I’m using it already as a “daily driver” because it’s pretty stable already)

Edit: and the newly created xml:

https://gist.github.com/sihui62/595c1cc544fd285dd5de474641c70315

2nd Edit: and yes, it’s still working after reinit:

2016-12-10 17:56:44.941 [ItemStateChangedEvent     ] - FibUniSens1_1 changed from OFF to ON
2016-12-10 17:56:44.963 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:46.859 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:56:47.014 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:48.499 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:56:48.604 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 11 to 10
2016-12-10 17:56:50.348 [ItemStateChangedEvent     ] - FibUniSens1_0 changed from 10 to 11
2016-12-10 17:57:05.359 [ItemStateChangedEvent     ] - FibUniSens1_1 changed from ON to OFF

[sihui]

@chris

and have deleted and re-added the thing since we made the changes to the DB?

I don’t get it: the warning message disappeared.
Sometimes I’m really lost in the jungle of openHAB debug log files … (not only for zwave).

I’m sure I did delete the device as thing and re-added it with the currently used snapshot. I did not do a re-initialization or deleted the xml file though.
Is that what I should have done after the database update?
If yes, sorry, my mistake …

[chris (Chris Jackson)]

@sihui

I did not do a re-initialization or deleted the xml file though.

This shouldn’t be needed (I think!). I think that the XML should be deleted when you remove the thing, although I’m not 100% sure.

Anyway, I don’t think that’s the issue here since the BASIC class was missing from the device endpoints. This probably means that there was some sort of error when the binding interrogated the device. I’ll take a look at your log to see if I can see where this gets defined, but in the upcoming version of the binding, this is done differently anyway as BASIC should always be included, and it’s not mandatory for a device to report that it’s supported.