Is that because you’re comparing against the weather map, and not accounting for your altitude?
Yes - you’ll need to use a dummy item I think. There’s no way to intercept a channel before it updates the thing (that I’m aware of anyway).
Good catch. I am at 190m above sea level. Rule of thumb: 21 hPa. Accounting for temperature and using a calculator: spot on. I won’t tell you how I make a living, that would be an embarrasment 
I am supposed to know this…
1 Like
I have the log now for the incorrect measurement part. Here is the standard log where you can see the problem, attached is the Zigbee Debug Log. Additionally this highligts another problem I have recently. The aqara devices stop responding after a short period of time. This is after I switched from one of the compiled bindings (2.2.0.201802192145) to the latest snapshot (march 10th and forward, I updated everything yesterday: OpenHAB, Openhabian, and the Zigbee binding)
I added two aqara devices yesterday evening and after a short period of time they stopped sending updates, this was both a door sensor and a temp sensor. They were very difficult to pair and get channels on, and now they wont send anything. This is also in the debug log. In the log below, that is the latest measurement from the temp sensor.
2018-03-13 22:30:36.742 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.10 to 24.00
2018-03-13 22:30:36.749 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:36.498+01:00
2018-03-13 22:30:36.753 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.00 to 23.95
2018-03-13 22:30:36.757 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:36.498+01:00
2018-03-13 22:30:36.779 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 23.95 to 23.92
2018-03-13 22:30:36.783 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:36.540+01:00
2018-03-13 22:30:36.818 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:36.540+01:00
2018-03-13 22:30:36.952 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:17:56.366+01:00 to 2018-03-13T22:30:36.498+01:00
2018-03-13 22:30:36.969 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:30:36.498+01:00 to 2018-03-13T22:30:36.540+01:00
2018-03-13 22:30:37.049 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 23.92 to 24.14
2018-03-13 22:30:37.062 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Pressure2 changed from 1002.4 to 100240
2018-03-13 22:30:37.085 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:37.037+01:00
2018-03-13 22:30:37.094 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:30:36.540+01:00 to 2018-03-13T22:30:37.037+01:00
2018-03-13 22:30:40.260 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.14 to 24.23
2018-03-13 22:30:40.304 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Pressure2 changed from 100240 to 1002.4
2018-03-13 22:30:40.354 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:40.270+01:00
2018-03-13 22:30:40.359 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:30:37.037+01:00 to 2018-03-13T22:30:40.270+01:00
2018-03-13 22:30:43.495 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.23 to 24.00
2018-03-13 22:30:43.553 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:43.521+01:00
2018-03-13 22:30:43.563 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:30:40.270+01:00 to 2018-03-13T22:30:43.521+01:00
2018-03-13 22:30:46.932 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.00 to 24.13
2018-03-13 22:30:46.969 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:30:46.956+01:00
2018-03-13 22:30:46.981 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:30:43.521+01:00 to 2018-03-13T22:30:46.956+01:00
2018-03-13 22:34:58.261 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.13 to 24.17
2018-03-13 22:34:58.330 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Pressure2 changed from 1002.4 to 1002.5
2018-03-13 22:35:00.456 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:34:58.284+01:00
2018-03-13 22:35:00.469 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:30:46.956+01:00 to 2018-03-13T22:34:58.284+01:00
2018-03-13 22:35:01.513 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.17 to 24.50
2018-03-13 22:35:01.649 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:35:01.527+01:00
2018-03-13 22:35:01.653 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Pressure2 changed from 1002.5 to 1002.4
2018-03-13 22:35:01.668 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:34:58.284+01:00 to 2018-03-13T22:35:01.527+01:00
2018-03-13 22:35:10.773 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 24.50 to 25.02
2018-03-13 22:35:10.886 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:35:10.850+01:00
2018-03-13 22:35:10.893 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:35:01.527+01:00 to 2018-03-13T22:35:10.850+01:00
2018-03-13 22:35:23.087 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2 changed from 25.02 to 25.27
2018-03-13 22:35:23.162 [ome.event.ItemCommandEvent] - Item 'FF_Kitchen_Thermostat_Temperature2_LU' received command 2018-03-13T22:35:23.116+01:00
2018-03-13 22:35:23.196 [vent.ItemStateChangedEvent] - FF_Kitchen_Thermostat_Temperature2_LU changed from 2018-03-13T22:35:10.850+01:00 to 2018-03-13T22:35:23.116+01:00
The full Zigbee debug logs are here:
Pairing and wrong decimal point: https://gist.github.com/petero-dk/f44210dd3c0af63f14e95934650f3606
Last report and lost connection: https://gist.github.com/petero-dk/8c68ee376ae628eab858dafef828128f
Is there anything I can do, or should have done?
Edit: Only the temp sensor seems to have lost connection, the door sensor is working again this morning
There’s probably not a lot that can be done to resolve this. I will look at the log, but these devices are known to have such issues and as they are not ZigBee devices it’s a bit difficult to manage this
Yeah, I can imagine, but what I find wierd is that worked rick solid until the latest update for the binding, and now it does feel so solid.
I have been doing some more testing, I can pair the door sensors quite easily.
- Start inclusion
- If they have never been paired with anything before/brand new!: Simply press their inclusion button once and they will show up in OpenHAB.
- If they have been paired before (OpenHAB or other) hold the include button down for 10 seconds until it blinks
- Get channels
Once every second until it saysOFFLINE: Node has not completed discoveryand the channels have shown up press the include button on the device - Once the channel has been created, assign it to an item (I do this in the items files) and open and close it once every second until the switch until the log files show that it opens and closes.
I do not know why I have to go through this, but it seems to be the way to get them to stick. Once they stick, they really do not leave. One of my devices was the one I mentioned first in this thread, and it has gone through binding upgrades, OpenHAB opgrades, restarts, etc. still works.
Personally, I would simplify this. In ALL cases, it is easiest to simply start join mode in the binding, and then reset the device. I would recommend this for all devices - not just Xiaomi. It’s a much safer method.
My problem is, that when I do that, the Xiaomi devices wont stay connected, after a couple of hours they stop sending updates.
Here is an example of a device that was paired and working, then suddenly stopped working. I could not get it back online, and then I removed it.
After I removed it, then I get a lot of ON/OFF switchings (about the same amount of ON/OFF that I have been missing, probably exactly the amount of ON/OFF that I have been mising), a few errors and then it is gone.
FF_Kitchen_Window_Sink_4 is zigbee:device:a042d5da:00158d0001657238
2018-03-15 13:50:33.595 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.IllegalArgumentException: Illegal status transition from REMOVING to ONLINE, only REMOVED would have been allowed.
at org.eclipse.smarthome.core.thing.internal.ThingManager$1.statusUpdated(ThingManager.java:161) [110:org.eclipse.smarthome.core.thing:0.10.0.201802191927]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus(BaseThingHandler.java:448) [110:org.eclipse.smarthome.core.thing:0.10.0.201802191927]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateStatus(BaseThingHandler.java:473) [110:org.eclipse.smarthome.core.thing:0.10.0.201802191927]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:265) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:156) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:150) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
==> /var/log/openhab2/events.log <==
2018-03-15 13:50:33.615 [me.event.ThingUpdatedEvent] - Thing 'zigbee:device:a042d5da:00158d0001657238' has been updated.
2018-03-15 13:50:33.624 [hingStatusInfoChangedEvent] - 'zigbee:device:a042d5da:00158d0001657238' changed from REMOVING to REMOVED
2018-03-15 13:50:33.666 [hingStatusInfoChangedEvent] - 'zigbee:device:a042d5da:00158d0001657238' changed from REMOVED to UNINITIALIZED
2018-03-15 13:50:33.692 [hingStatusInfoChangedEvent] - 'zigbee:device:a042d5da:00158d0001657238' changed from UNINITIALIZED to ONLINE
2018-03-15 13:50:33.695 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from OFF to ON
2018-03-15 13:50:33.701 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from ON to OFF
2018-03-15 13:50:33.716 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from OFF to ON
==> /var/log/openhab2/openhab.log <==
2018-03-15 13:50:33.718 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) [?:?]
at com.zsmartsystems.zigbee.ZigBeeNetworkManager.getNode(ZigBeeNetworkManager.java:1105) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeCoordinatorHandler.getNode(ZigBeeCoordinatorHandler.java:641) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:161) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.access$0(ZigBeeThingHandler.java:156) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:150) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [214:org.openhab.binding.zigbee:2.3.0.201803101457]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
==> /var/log/openhab2/events.log <==
2018-03-15 13:50:33.747 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from ON to OFF
2018-03-15 13:50:33.760 [hingStatusInfoChangedEvent] - 'zigbee:device:a042d5da:00158d0001657238' changed from REMOVED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2018-03-15 13:50:33.761 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from OFF to ON
2018-03-15 13:50:33.774 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from ON to OFF
2018-03-15 13:50:33.776 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from OFF to ON
2018-03-15 13:50:33.779 [vent.ItemStateChangedEvent] - FF_Kitchen_Window_Sink_4 changed from ON to OFF
Zigbee debug log: https://gist.github.com/ab0b82bea80e1339fc4b204930a745ca
Gents
If I get a Chinese cc2531 dongle, do I also need a flasher plus cable to write the necessary fw or is the cc Downloader enough these days?
Edit. Yes. It does look like that’s the case. I will ask more about this in another thread.
I also have a problem getting the Xiaomi Aqara Temperature and Humidity Sensor to work properly. I can easily add it to Openhab, and it is discovered with every channel.
But after some minutes or hours, the device is shown as offline. I don’t know why this happens and would like to help to debug this issue.
@cdjackson are there any logs I should provide?
This sort of issue is not uncommon for the Xiaomi - especially for the older versions. Please remember, these are not ZigBee devices and I’m not sure that there’s a lot I can do.
Personally, I’ve found the new Aqara devices seem to work ok, and the older devices don’t, but that’s just my experience and I’ve seen information on the ST forum about the same sort of problems (ie devices dropping off the network).
The sensor I am using is the newest one, square shaped with round corners, with the word “zigbee” printed on the backside, though I know they might not be fully zigbee compliant.
If you think theres a little chance to fix it when someone provides detailed logfiles, let me know and tell me what to post. I am willing to help by whatever I am supposed to do.
If you can capture a log with something useful (I don’t know what that is as we don’t know what the problem is) then I’m happy to take a look. The problem is that these sort of issues may not be captured in a log as they are interactions between the coordinator and the device, and you will therefore only see them if you have a network sniffer.
Let’s see - maybe it’s not that - maybe the issue is in the binding in which case the log will help…
Also, please confirm what version of the binding you are using? I assume the latest?
I have installed the snapshot branch of openhab and did an apt-get upgrade prior adding the Xiaomi device. So I’m pretty sure I’m using the latest snapshot of openhab and the binding too.
I had similar experiences. Although I don’t have the log to hand the interesting bit was that there was a “node leaving network” packet received just before the device went offline.
Hopefully I will have some time tonight to re-add my square Aqara sensor and help get additional log files.
I think I have seen something like this too, but I don’t remember in which logfile. Can you tell me which log I should look into?
The openhab.log file. You need to enable debug logging of course first…
OK, I have enabled debug level logging. I will start with the Xiaomi sensor from scratch this evening and post a complete log.
Hello guys,
We have created 2 new products, compatible with OpenHAB ZigBee bindings:
Both of them are compatible and tested with latest OpenHAB and latest Z-Wave Binding.
We have also prepared User Guides on how to set them up.
Hope you find them useful.
1 Like
Exactly what I was looking for - unfortunately only for windows?
Could it be running on a virtual Ubuntu machine when the OpenHAB is running on the windows machine?
Or will there be any drivers for windows?