I just gave it another try with factory resetting the eurotronic before triggering discovery.
Changes nothing for me, but you´re sure that this is the way it had to be done? Factory resetting every time a join fails? Although they are freshly from factory and never were connected to anything before? Cant believe it, but ok i keep trying it with a factory reset before every discover.
Chris: Don´t know why you cannot see my log i posted in my second post before this, i put the relevant part into a blockquote?
Anyway i am going to attach the complete log to this post, just if you want to throw a look into.
The last test i did starts at line 9726, but you can see there that every test before has the same output, just timestamp is different.
edit: sorry cant upload the complete log, because file size is limited to 1048 kb -.- I shortened out a few thousand lines from end of dezember which are just showing the same output as now and always. Go to line 6513 now for my last attempt.openhab[shortened].log (992.3 KB)
You must reset a device since you do not know what state it is in. If it partially joined a network, then it will never join another network.
Maybe the Spirit has a way to always reset itself if it fails, but by far the safest and easiest way to include a ZigBee device from a known state is to reset it.
Ok, sorry, I didn’t realise that is what you refer to as a log. That is totally insufficient to understand what is happening. I need a reasonable amount of logging to understand the context and what state things are in - a single message received from the dongle is completely useless - sorry.
I will take a look at the full log you’ve now posted a little later.
So here is what my attempt with the Raspberry Pi brought up:
I installed a freshly copy of openhabian 2.5.0-1 from openhab.org to microsd, powered the raspberry up (just power cord and network connected). Waited a while for it to come up. After it was up and ready i connected the BitronVideo Coordinator to the USB-Port. It came up as /dev/ttyAMA0. Then i looked up the inbox in paperui, which was empty. Tried to add it manually but it doesn´t came online. Next step i listed the loaded kernel modules where the cp210x was missing. Tried to modprobe it, but rans into an error. Then rebooted the Pi, now the kernel module cp210x was loaded from startup (dunno what was wrong with it in first place) and the Coordinator showed up in inbox, i added it and it came online like on my x86-server before.
Next i tried one Eurotronic to join (with a factory reset this time) and it showed up in inbox, firstly as a unknown device (added it, but didn´t came online) so i deleted it and did an discover again, when it showed up i waited until it changed from unknown device to “Eurotronic SPZB0001” and added it then. This time it is shown as online. But on the Device itself the “Boost”-Button never flashed green (which should indicate that a joining attempt is registered) and after a while it shows “Err” as its not properly initiated. Tried to retrigger this by checking the box “initiate Device” in Thing settings. Changed nothing.
So conclusion:On the raspberry Pi i successful the devices can find each other but is not working correctly at all.
So I guess maybe the updated Libraries would fix the problem that i run into in my raspberry Pi setup. But my main problem on my x86-machine seems nothing to do with it as the devices can´t communicate with each other in first place.
I am adding my Log from the openhabian on raspberry setup for further researchs. openhab.log (117.4 KB)
My guess is that the reason behind this failure is that you have a noisy RF environment. The binding sends 2 Join commands - one to the coordinator itself, and one is broadcast. The one to the coordinator is not required for Ember - it was added to solve a problem with the TI dongle.
However, this still means that join is enabled in the coordinator even if other routers in the network will not be able to enable join. It still means that if your joining device is looking for a network, then the coordinator will allow it to join, so it still should be able to join…
However… The failure to send the broadcast is likely a MAC issue (although I can’t prove that from what I can see). This is normally due to high RF levels not allowing the CSMA algorithm to determine a clear point to transmit, and then the command fails. This is currently the only explanation I can provide - I’m not necessarily saying it’s THE reason, but it is ONE possible reason (but there aren’t too many reasons a broadcast won’t be sent and most of the others are ruled out by the fact that the command was accepted and queued in the first place).
Would temporarily moving the thermostat and Zigbee coordinator closer together possibly permit the initial join or would you expect major Zigbee communication issues afterward?
No - this wont help. If I’m right, then the problem is RF noise. This can’t be overcome by moving devices closer since the underlying issue here is CSMA - ie the device will not transmit until it has a clear channel. This can only be fixed by solving the noise issue, or moving to a clear channel.
I think this should be near enough
All my attempts so far the devices were closer than 1 m each other.
So what to do about it? Can´t really believe there is more RF noise around my home than everywhere else in “civilizated” areas. I am livin in a really small town (less 5000 population), of course there is some wlan, dect, gsm etc. around, but I think in bigger citys with more crowded population there would be much more noise.
Should i try to switch channel in Coordinator´s settings? Don´t they use channel hopping anyway?
This is a really bad idea! I strongly suggest to move them further apart as this sort of thing can cause exactly what I describe above. You might also want to get a USB lead and separate the ZigBee dongle from the RPi.
This is an issue I’ve personally seen recently just by having 2 Ember dongles plugged in to the same USB hub. These sort of issues are normally quite local - I already provided some suggestions above.
Many civilized areas, like a college or University environment provide only “as is” support for 2.4 GHz Wi-Fi because so many other devices such as microwave opens and wireless phones also tend to use this unregulated RF space,
We did quick troubleshooting on Wi-Fi in one area just to discover they had moved a microwave oven right beneath the wireless access point. Moving the AP helped servuice issues there immensely.
Oh I wasn´t aware its using 2,4Ghz. I thought it will be using frequencies around 868 Mhz which i just read zwave does (in Europe).
If this really should be the problem with it, i consider to send the devices back or sell them and change to zwave.
Which Channel map to which frequency? I am a little confused as my router states it has a range from channel 1 to 13 what are shown as frequency 2,412Ghz to 2,472Ghz.
But in Openhab i´ve got channel from 11 to 25 for my zigbee coordinator to chose from. My router (fritzbox) allows me to see on which channel there is some crowding and on which are not. But don´t know how they correlate each other.
Anyway I will keep testing some variations this day and looking forward for the updated libraries coming. But if that doesn´t help, never mind, then i am going to use zwave devices instead.
Is this supposed to work now with 2.5.1 as the pull request was merged?
I can discover the Thermostat with my BitronVideo Stick and it is shown in Paper UI as “ONLINE”, but the thermostat itself is showing “Err” and tries to join again after pressing the “Boost” button. I have reset the Thermostat numerous times, but it makes no difference.
Should this work now and it’s a problem on my side or is this still a work-in-progress and I just need to be patient?
(I’m using the 2.5.1-2 Debian package on a Raspberry Pi 4 with standard Raspbian.)
Just tried out the 2.5.2-SNAPSHOT from 8 hours ago and joining worked fine.
If somebody is interested in these thermostats there are five channels available:
Occupied Cooling Setpoint
Unoccupied Heating Setpoint
Local Temperature
Occupied Heating Setpoint
System Mode
Although I don’t know what all these channels except Occupied Heating Setpoint and Local Temperature are for. And unfortunately the battery status and the local temperature calibration is not accessible although those attributes are described in the documentation.
I would have expected battery state channel, but I will need to look at what service this actually providing as there are a few ways to provide this information.
Temperature calibration is not something that I’ve supported at the moment but please raise an issue and I can take a look at it when I get a chance.
I could also post a logfile of the device joining if this would help. Although the attribute 0x21 (33) <name>Battery Percentage Remaining</name> is present in the XML file, but is listed as <implemented>false</implemented>. Well, OK, maybe that does not mean anything as all attributes in the XML file are marked as not implemented.
That’s really not that important. It’s just a convenience if somebody is adjusting the temperature on the thermostat itself. Everything else could be handled inside OpenHAB.
Great - thanks for the feedback.