EU Zigbee dongle

Just let me know what I should do, I have forked the repository so I can work on it. I know in order to get battery level and the air pressure you need to parse some standard ZigBee messages (catchall I think) the humidity is another standard cluster.

Also one of the things that SmartThings have problems with is to keep the items paired over time, I will do some testing on that aspect (I tried today however my entire OpenHab stopped responding sometime last night)

Fyi I am running the tests on a Windows 10, and will move the setup to a Rpi

Just so this is documented somewhere:

The Telegesis stick (ETRX357USB in the first link) works out of the box with OpenHAB, no programming of the stick necessary. However getting the stick to work on Windows is not standard:

  1. Plug it in Windows will say installing and label it Telegesis but not working in the Device Manager
  2. Download the ā€œCP210x USB to UART Bridge VCP Driversā€ from Silabs (currently the working link is: https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers)
    2a) Unzip the driver
  3. Right click the Telegesis device in Device Manager and select Update Driver
  4. Skip the auto search for driver, and in the first device list select ā€œAll Devicesā€ this is stupid as Windows will now load a list of possible device drivers for you to chose, ignore all the loading and quickly click the button ā€œHave Diskā€ as if you are in the 90ā€™s
  5. Find the inf file in the driver package you downloaded in step 2) and remembered to unzip in 2a) and select it.
  6. Windows will complain that it cannot verify that the device can use this driver as the device is not listed in the driver configuration file. Ignore this as the telegesis usb stick is exactly a CP210x device, it will work.
  7. Do the OpenHab thing.

I am just spamming this thread, sorry. I did some more testing here, after a reboot both sensors were offline. Then I was just pressing the wakeup button on the temp sensor and suddenly the logs showed new measurements. Pressing the button on the door sensors and opening closing the ā€œdoorā€ yielded no updates.

Then I started a ZigBee device search from PaperUI while I was opening and closing the device, and it started updating again.

Default logs included, unfortunately i forgot to set debug logs to on, will do that from now on:

12:24:40.501 [INFO ] [arthome.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:device:2c6560c8:00158d0001a65fdb changed to UNKNOWN.
12:24:40.507 [INFO ] [arthome.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:device:2c6560c8:00158d0001ab2969 changed to UNKNOWN.
12:25:46.620 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:device:2c6560c8:00158d0001ab2969' has been updated.
12:25:46.642 [INFO ] [gbee.discovery.ZigBeeDiscoveryService] - 00158D0001AB2969: Starting ZigBee device discovery
12:25:46.692 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:device:2c6560c8:00158d0001ab2969' has been updated.
12:25:53.295 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:2c6560c8:00158d0001ab2969' changed from OFFLINE: zigbee.status.offline_nodenotfound to ONLINE
12:25:53.299 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from NULL to 25.10
12:26:08.712 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.10 to 25.25
12:26:11.989 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.25 to 25.27
12:26:15.409 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.27 to 25.28
12:26:21.572 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.28 to 25.35
12:26:28.752 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.35 to 25.31
12:26:31.988 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.31 to 25.40
12:26:35.627 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.40 to 25.31
12:26:38.972 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.31 to 25.34
12:27:26.842 [INFO ] [gbee.discovery.ZigBeeDiscoveryService] - 00158D0001AB2969: Starting ZigBee device discovery
12:27:29.269 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:device:2c6560c8:00158d0001a65fdb' has been updated.
12:27:29.282 [INFO ] [gbee.discovery.ZigBeeDiscoveryService] - 00158D0001A65FDB: Starting ZigBee device discovery
12:27:29.299 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zigbee:device:2c6560c8:00158d0001a65fdb' has been updated.
12:27:31.460 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zigbee:device:2c6560c8:00158d0001a65fdb' changed from OFFLINE: zigbee.status.offline_nodenotfound to ONLINE
12:27:31.472 [INFO ] [smarthome.event.ItemStateChangedEvent] - DoorSensor_Switch changed from NULL to OFF
12:27:31.621 [INFO ] [smarthome.event.ItemStateChangedEvent] - DoorSensor_Switch changed from OFF to ON
12:27:54.175 [INFO ] [smarthome.event.ItemStateChangedEvent] - DoorSensor_Switch changed from ON to OFF
12:27:54.920 [INFO ] [smarthome.event.ItemStateChangedEvent] - DoorSensor_Switch changed from OFF to ON
12:27:55.696 [INFO ] [smarthome.event.ItemStateChangedEvent] - DoorSensor_Switch changed from ON to OFF
12:28:32.156 [INFO ] [smarthome.event.ItemStateChangedEvent] - TemperatureSensor_Temperature changed from 25.34 to 25.85

Yes, this was the problem with the original Xiaomi devices as they were not ZigBee compliant and I believe didnā€™t implement the rejoin process properly. This is something that may be a problem though as this is not something you are likely to be able to change as itā€™s normally managed within the coordinator itselfā€¦

Letā€™s see - hopefully itā€™s fixed in the new devices.

Currently the binding requires some information from the sensors which can take some time to update. Until this is complete the devices are offline. Itā€™s on my list of things to improve and this is partly implemented.

Unfortunately without the debug log level, this doesnā€™t provide any information at all :frowning: - sorry.

I am new to zigbee and looking for a usb stick that works out of the box with the openhab binding. I am located in Germany.
I found the following sticks:

  • mediola Zigbee USB-Stick
  • ConBee USB Gateway
  • ZigBee USB Funkstick from Bitron

and the XStick USB Adapter from DIGI which is used by the Mozilla Internet of Things project in the Things Gateway.

Any recommendations?
These usb sticks cost between 30 ā‚¬ and 40ā‚¬ at the moment.

Hi Holger

The first link I posted above on Mouser should take you to what you need, it will give you the Telegesis dongle which works out of the box. Mouser is a global site and have local presence in almost all of Europe (incl Germany) so you should be good there.

So iā€™ve just stupidly ordered the xstick (https://www.mouser.com/ds/2/111/ds_xstick-794441.pdf) thanks to the mozilla iot project without finding this post first! Is there any hope of this device working? If not out of the box can someone give me pointers on where to start in writing the support myself? I have some development experience (and have written a couple of openhab bindings but not yet released them) so hopefully I can knock some code up if thereā€™s no support currently!

Chris

No - itā€™s not supported.

See this repo. If you want to add support for a new dongle then you can find the existing dongles there and a PR for another dongle would of course be great :slight_smile: .

Guess iā€™ve got some work to do then!!

Hi @chris

Iā€™ve got a Telegesis dongle and Iā€™ve paired my Xiaomi motion sensor to it. I can see a load of log entries from the zsmartsystems library whenever I trigger the motion sensor but itā€™s not creating a Thing in OH. Whereā€™s the best place to start debugging?

Hereā€™s a log snippet:

2018-02-10 15:00:03.381 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 37 36 38 41 2C 30 31 30 34 2C 30 31 2C 30 31 2C 30 34 30 36 2C 30 37 3A 18 08 0A 00 00 18 01 2C 2D 34 32 2C 46 45
2018-02-10 15:00:03.389 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=30346, profileId=260, destinationEp=1, sourceEp=1, clusterId=1030, messageData=18 08 0A 00 00 18 01, rssi=-66, lqi=254]
2018-02-10 15:00:03.395 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=30346, profileId=260, destinationEp=1, sourceEp=1, clusterId=1030, messageData=18 08 0A 00 00 18 01, rssi=-66, lqi=254]
2018-02-10 15:00:03.401 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=30346/1, destinationAddress=0/1, profile=0104, cluster=1030, addressMode=null, radius=0, sequence=0, payload=18 08 0A 00 00 18 01]
2018-02-10 15:00:03.405 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=8, commandId=10]
2018-02-10 15:00:03.410 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Occupancy sensing: 30346/1 -> 0/1, cluster=0406, TID=08, reports=[Attribute Report: attributeDataType=BITMAP_8_BIT, attributeIdentifier=0, attributeValue=1]]
2018-02-10 15:00:03.416 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 30346: Scheduling node discovery
2018-02-10 15:00:03.421 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 30346: Starting node discovery
2018-02-10 15:00:03.425 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: IeeeAddressRequest [0/0 -> 30346/0, cluster=0001, TID=21, nwkAddrOfInterest=30346, requestType=1, startIndex=0]
2018-02-10 15:00:03.430 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=30346/0, profile=0000, cluster=1, addressMode=DEVICE, radius=31, sequence=33, payload=00 8A 76 01 00]
2018-02-10 15:00:03.436 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 8A 76 01 00, messageId=null]
2018-02-10 15:00:03.442 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1
2018-02-10 15:00:03.449 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 8A 76 01 00, messageId=null]
2018-02-10 15:00:03.486 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS TX: Data 41 54 2B 53 45 4E 44 55 43 41 53 54 42 3A 30 35 2C 37 36 38 41 2C 30 30 2C 30 30 2C 30 30 30 30 2C 30 30 30 31 0D 00 8A 76 01 00 0D 0A
2018-02-10 15:00:03.642 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 53 45 51 3A 34 33
2018-02-10 15:00:03.648 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 4F 4B
2018-02-10 15:00:03.651 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis command complete: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=1, messageData=00 8A 76 01 00, messageId=67, status=SUCCESS]
2018-02-10 15:00:03.658 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 41 43 4B 3A 34 33
2018-02-10 15:00:03.660 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisAckMessageEvent [messageId=67]
2018-02-10 15:00:03.663 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisAckMessageEvent [messageId=67]
2018-02-10 15:00:03.666 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Unhandled Telegesis Frame: TelegesisAckMessageEvent [messageId=67]
2018-02-10 15:00:03.685 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 52 58 3A 30 30 30 30 2C 30 30 30 30 2C 30 30 2C 30 30 2C 38 30 30 31 2C 30 44 3A 00 00 EB 86 5A 01 00 8D 15 00 8A 76 00 2C 30 30 2C 46 46
2018-02-10 15:00:03.690 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis event received: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=0, profileId=0, destinationEp=0, sourceEp=0, clusterId=32769, messageData=00 00 EB 86 5A 01 00 8D 15 00 8A 76 00, rssi=0, lqi=255]
2018-02-10 15:00:03.696 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis RX: TelegesisReceiveMessageEvent [ieeeAddress=null, networkAddress=0, profileId=0, destinationEp=0, sourceEp=0, clusterId=32769, messageData=00 00 EB 86 5A 01 00 8D 15 00 8A 76 00, rssi=0, lqi=255]
2018-02-10 15:00:03.701 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=0/0, profile=0000, cluster=32769, addressMode=null, radius=0, sequence=0, payload=00 00 EB 86 5A 01 00 8D 15 00 8A 76 00]
2018-02-10 15:00:03.706 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: IeeeAddressResponse [0/0 -> 0/0, cluster=8001, TID=NULL, status=SUCCESS, ieeeAddrRemoteDev=00158D00015A86EB, nwkAddrRemoteDev=30346, startIndex=null, nwkAddrAssocDevList=[]]
2018-02-10 15:00:03.722 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 30346: Ieee Address returned IeeeAddressResponse [0/0 -> 0/0, cluster=8001, TID=NULL, status=SUCCESS, ieeeAddrRemoteDev=00158D00015A86EB, nwkAddrRemoteDev=30346, startIndex=null, nwkAddrAssocDevList=[]]
2018-02-10 15:00:03.728 [DEBUG] [com.zsmartsystems.zigbee.ZigBeeNode ] - 00158D00015A86EB: Associated devices table unchanged
2018-02-10 15:00:03.732 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 30346: Discovery request IEEE_ADDRESS successful. Advanced to NODE_DESCRIPTOR.
2018-02-10 15:00:03.738 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: NodeDescriptorRequest [0/0 -> 30346/0, cluster=0002, TID=22, nwkAddrOfInterest=30346]
2018-02-10 15:00:03.743 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=30346/0, profile=0000, cluster=2, addressMode=DEVICE, radius=31, sequence=34, payload=00 8A 76]
2018-02-10 15:00:03.748 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=2, messageData=00 8A 76, messageId=null]
2018-02-10 15:00:03.752 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1
2018-02-10 15:00:03.757 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=2, messageData=00 8A 76, messageId=null]
2018-02-10 15:00:03.771 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS TX: Data 41 54 2B 53 45 4E 44 55 43 41 53 54 42 3A 30 33 2C 37 36 38 41 2C 30 30 2C 30 30 2C 30 30 30 30 2C 30 30 30 32 0D 00 8A 76 0D 0A
2018-02-10 15:00:03.900 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 53 45 51 3A 34 35
2018-02-10 15:00:03.914 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 4F 4B
2018-02-10 15:00:03.917 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis command complete: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=2, messageData=00 8A 76, messageId=69, status=SUCCESS]
2018-02-10 15:00:13.777 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 30346: Node Descriptor returned null
2018-02-10 15:00:13.779 [DEBUG] [bee.internal.ZigBeeNetworkDiscoverer] - 30346: Node discovery request NODE_DESCRIPTOR failed. Wait before retry.
2018-02-10 15:00:15.285 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: NodeDescriptorRequest [0/0 -> 30346/0, cluster=0002, TID=23, nwkAddrOfInterest=30346]
2018-02-10 15:00:15.290 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX APS: ZigBeeApsFrame [sourceAddress=0/0, destinationAddress=30346/0, profile=0000, cluster=2, addressMode=DEVICE, radius=31, sequence=35, payload=00 8A 76]
2018-02-10 15:00:15.294 [DEBUG] [ngle.telegesis.ZigBeeDongleTelegesis] - Telegesis send: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=2, messageData=00 8A 76, messageId=null]
2018-02-10 15:00:15.305 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis queue: 1
2018-02-10 15:00:15.310 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TX Telegesis: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=2, messageData=00 8A 76, messageId=null]
2018-02-10 15:00:15.327 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS TX: Data 41 54 2B 53 45 4E 44 55 43 41 53 54 42 3A 30 33 2C 37 36 38 41 2C 30 30 2C 30 30 2C 30 30 30 30 2C 30 30 30 32 0D 00 8A 76 0D 0A
2018-02-10 15:00:15.454 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 53 45 51 3A 34 36
2018-02-10 15:00:15.461 [DEBUG] [gesis.internal.TelegesisFrameHandler] - TELEGESIS RX: Data 4F 4B
2018-02-10 15:00:15.465 [DEBUG] [gesis.internal.TelegesisFrameHandler] - Telegesis command complete: TelegesisSendUnicastCommand [address=30346, sourceEp=0, destEp=0, profileId=0, clusterId=2, messageData=00 8A 76, messageId=70, status=SUCCESS]

Give me a day or so to look over this. Iā€™m currently doing some significant refactoring of the discovery and mesh update code and will look at this at the same time. The refactoring is basically done - just need to complete testing.

Iā€™ve also got the sensor here now so can easily test this and will take a look tomorrow - my current testing is with the temp/humidity/pressure sensor which Iā€™ll add support for shortly.

From a quick look at the log, I have a question - are you continually waking the device up - ie pressing the button every few seconds? Itā€™s well documented that they go to sleep super quick and need to be kept awake while services are discovered.

Iā€™ve just tried your suggestion (pressing the button every few seconds whilst OH is running discovery) and still nothing - same for the motion sensor (v1) and the temp/humidity/pressure sensor I have. Iā€™m 90% sure theyā€™re paired with the dongle - can you run through the rough stages of what needs happen for OH to discover a paired device? As I may be misunderstanding the process.

Thanks

Assuming this node thatā€™s in your log is the device, then itā€™s paired, otherwise it wouldnā€™t be in the log.

After association, the binding tries to gather information about the device - what it is, what services it supports etc. Sorry - I have to go out shortly and have very limited time.

Here the device is not responding to a basic request so it looks like thereā€™s no communications which with these devices is normal if they donā€™t wake up. In theory certified ZigBee battery devices are meant to wake up every 7.6 seconds to check for new requests from their parent, but many cheaper sensors donā€™t respect that and it means communications fails.

Thanks. So based on that Iā€™ve managed to get a bit further. Waking the device up every few seconds during OH discovery and checking the logs better I can see the devices are going through the following stages:

  1. NODE_DESCRIPTOR
  2. POWER_DESCRIPTOR
  3. ACTIVE_ENDPOINTS
  4. DISCOVERY_END

I also noticed the following log line for the motion sensor:

2018-02-10 15:41:57.088 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Basic: 30346/1 -> 0/1, cluster=0000, TID=01, reports=[Attribute Report: attributeDataType=CHARACTER_STRING, attributeIdentifier=5, attributeValue=lumi.sensor_motion]]

So itā€™s at least reporting what it is although still no OH inbox entry.

The newer temp/humidity/pressure sensor DID result in an inbox entry although the Thing label said ā€œUnknown ZigBee Device XXXXXXXXXXXXXXXXā€ and had only one channel.

Still, thatā€™s progress.

Have a good weekend!

Edit: the motion sensor has finally created a Thing too although isnā€™t updating the channel/item state.

I ended up getting mouser to change my order to the telegesis dongle and itā€™s working nicely. I have 8 Ikea gu10s dimming nicely! The wireless dimmers are also detected but as a switch device though I canā€™t seem to get openhab to respond to moving them. Is there anything I can do to help get them supported?

Hi @chris, sorry about the delay in testing. I had this running on my laptop and then for production switched everything over to openhabian on the pi3, which destroyed my KNX setup. So I have been wrestling with that monster for some time now.

I have had the Xiaomi Aqara Temp sensor attached for about a week now, and it has been rock steady. It does however measure the pressure sometimes with the wrong decimal point (103190.0 bar instead of 1031.90 bar) just once in a while (do you need logs for that)

The Door/Window sensor is a pain to get paired, it takes multiple tried to find it, and while it is pairing I need to press the button every once in while to get the channels. However I had not had one attached (and paid enough attention) to know how stable. I will commence that testing now.

Btw I am sending the temp readings from the Aqara humidity sensor and temperature to the KNX bus as additional readings for a Vimar Touch Thermostat. This is pretty darn cool.

I now have full rolling debug logs for ZigBee so I can test and log everything.

I am running version 2.2.0.201802192145 of the ZigBee binding and 2.2 stable OpenHab

Iā€™ve tested here with the Xiaomi sensors. Iā€™m not convinced they properly support ZigBee, but they seem to work ok if they are in direct range of the controller. From my tests, they donā€™t seems to join via another router, and they donā€™t implement some of the management commands required by ZigBee. Other than that, I agree they seem to work ok - it would be really nice if the next gen solved these issues, but letā€™s see :wink:

Iā€™ve not seen this here - if you can capture it in a log then please send the log and Iā€™ll have a look. If I remember correctly, pressure is provided in two different attributes - if the device is sending incorrect information then thereā€™s probably not much I can do, but if the binding isnā€™t correlating it correctly, then thereā€™s hope :slight_smile: .

I completely forgot to find the log for the decimal point thing. I will capture a log of that the next time i notice it.

I have however tried to find yet another Xiaomi thing. This is their first door/window sensor (the oval ones, the new ones are square). I had forgot that I had two of them up that I had used with Samsung Smartthings.

I managed to get one paired with the binding, and for a brief second it showed with a channel of switch, then I could not get it to wake up so I deleted it and tried to add it again (that is what usually works with the new ones if I cannot get them to work)

Now I cannot get anything other than offline / uninitialized from the old device.

I have attached a debug log from the binding for the [add] [get channel] [delete] [add] time period. The device is the 00158d00010af5d5. There might be a new Aqara device just before that I added.

Log: https://gist.github.com/petero-dk/36c7dd21a5e6193c6107676205d04d05

I now have the Xiaomi Aqara Smart Air Pressure Temperature Humidity Sensor installed. I noticed that it took almost a day to get the channels recognized.

One issue is that the pressure is consistently reported 24 hPa too low. So I would like to apply a correction. Is there any way to do that in a rule? Or would I have to create a dummy item which I would populate with measured pressure + 24?