Another Zigbee Repeater Solution (With Temperature, Humidity, Pressure and Light sensors)

project_sensors

(Tony Fleisher) #303

Is it intentional that the retry and fail counts only count up to 65535 and then remain there until device is reset?


(Iman Haryadi) #304

I will have to double check on the code. This is part of the framework. I will let you know as soon as (or if) I found the code.

I also will double check on the spec how Zigbee specify overflow.


(Iman Haryadi) #305

Hi Everyone,

I have been meaning to recap what we have done with the module/sensor project in 2018. I want to thanks to community members here with your feedback and donation.

Here is a picture how the project evolved.

  1. This is the first module that I shared with the community. It is just a simple Zigbee Repeater.
  2. In the second iteration, the module gains Temperature, Humidity, Pressure and Light sensor.
  3. The next improvement, the module allow user to add additional sensor or component through exposed Digital Input/Output pin and Analog Input.
  4. In latest iteration, as we are closing out the year 2018, the module add battery backup

Through out these iterations, I try to focus on adding feature to improve our experience with our Smart Home. In summary, here are highlights of what we have so far.

  • A Zigbee 3.0 repeaters(routers) compatible with Major Zigbee devices in the market. (work nicely with Xiaomi devices).
  • An Environmental Sensor for your room with reliable and prompt reporting sensor reading.
  • Expand-able module with additional sensor for DIY-er.
  • Battery backed up module that combine the best of both world of battery operated sensor and dc powered sensor.

Moving forward, I want to share what I think a good investment for the project. I would like to optimize the parts and board design. In turn, I would like to make more consistent build across modules. I also would like to see whether we can scale the build to higher quantity.

Again, I want to thanks everyone for the feedback. For those who take risk on this project and donate, I really appreciate it. My goal is to build a working module on every steps for all of us.

Thanks
Iman


(Iman Haryadi) #306

Just want to update everyone that I do not have the small module to share anymore. I still have six of the bigger (with 18650 battery case) module left.


(Håvard Kolberg) #307

Hi, level 0 here. Not able to send PMs. Any idea? Perhaps if you initiate?


(Joe ) #308

I’m having a strange issue and I’m hoping someone here can help me make sense of it. The repeater is working amazingly for keeping my xiaomi sensors and any other child device on the network. What I’ve noticed is that the repeater seems to be pairing as a child of another router device. That works fine, until I try to make changes to the router that the module is connected to. When I remove the parent router, the repeater module wants to stay with it and it doesn’t look for a new route to the coordinator.

When I posted about issues I was having earlier in this forum, it was because my module had paired to an Ikea bulb and it stopped responding when I moved the Ikea bulb from ST to my hue hub. I somehow stopped the module from routing through the Ikea bulb, but now it has become attached to my gledopto RGB strip controller. When I unplug the gledopto, the repeater module stops working and won’t look for a new route. I’ve tried everything I can think of to break this connection, but the module doesn’t want to work unless the gledopto controller is present in my ST mesh now. Has anyone else seen this? Any suggestions on how to get the module to forget the gledopto controller?


(Dan) #309

Have you tried rebuilding your Zigbee mesh? If you unplug (and remove batteries, if applicable) from the ST hub for at least 15 to 20 minutes, all of the Zigbee devices should go into a panic mode. After plugging your ST hub back in, all of the devices will find an optimal route back to the hub.


(Joe ) #310

I’ve tried rebuilding the mesh with the gledopto controller powered and unpowered. When I do it with the gledopto powered, the module stays connected through it like it was previously. When I do it without the gledopto powered, the module doesn’t respond after the rebuild until I plug the gledopto back in. I put the module a couple feet away from the ST hub during both attempts. My next thought was to move the gledopto really far away from the hub during the rebuild, it’s a couple rooms away right now but maybe I’ll just put it in the garage.


(Dan) #311

If you reset the environment sensor module (without removing it from ST), and then re-pair it to the hub with the gledopto powered off, it should resolve the issue. The device should “pop back into” the original ST device.


(Joe ) #312

That’s what I was expecting to happen. I just tried again, the gledopto is off and I pulled the module out then plugged it back in while holding the button for 3-4 seconds. Waited 10 seconds for it to fully reset, then started searching for things in ST. It doesn’t find anything and the ST device hasn’t updated. I did notice this time that I got a couple of sporadic updates on the module after unplugging the gledopto. Only a few updates to the light sensor and txfail jumped a bit, very irregular intervals which is weird because this thing usually responds like clockwork. But I haven’t had any activity from the sensor since about 2-3 minutes after turning off the gledopto. I also have an xbee scanning my mesh and it doesn’t see the module or any of the paired child devices.


(Tony Fleisher) #313

I have 4 of these sensors (2 from an early batch and 2 more recent with the led light). these are the only zigbee repeaters in my network.

last week I unplugged the devices because I was seeing problems with other zigbee devices and they have now been off for 6 days. the intermittent problems with lost events from my contact sensors have not appeared in this time.

today I went to plug back in the two later model sensors (designed for battery, no battery attached), and found that they do not appear to be communicating with the hub… no hub events or device events are seen in logs or events lists. I also tried resetting one by holding the button and it didn’t seem to help any.
seems something is strange with the device software.


(Joe ) #314

I wonder if your new modules were paired through your old ones like I’m seeing with other router devices. If you plug in all 4 do they all wake up?

I have one of the newer versions with the battery connection, not using a battery at the moment either. I haven’t noticed any dropped events to speak of, but my xbee mapping is showing a weak connection to the gledopto controller that it’s binding to for some reason. That’s why I’m trying to switch things around, I’ve noticed the module likes some routing devices more than others according to what the xbee is telling me. It hated my Sylvania bulbs, but the Ikea bulbs and iris plugs seemed to hold a strong connection.


(Iman Haryadi) #315

Hi Tony, I have replied to your PM. The pairing issue (assuming that the module has been factory reset) on the newer module is due to voltage regulator. Just let me know on the PM if you want me to replace them.


(Iman Haryadi) #316

Zigbee has rather complex routing mechanism.

My experience with XBee (I own a few as well) is hard to determine the real routing path. With some time, I may be able to track the route with sniffer.

Zigbee has parent child relationship. This impact heavily on sleepy end devices. Sleepy end devices will route all its packet to parent.

A router to router (router to coordinator/hub) is much more complex. In this case, there is a neighbor table in play before routing table. If this sensor see the hub as its neighbor, a packet will not be necessary sent to its parent. The sensor can say “oh the hub is in my range”. Lets send the packet directly. The other mechanism is “multi to one route”. ST hub use this mechanism as well. A packet can be sent to the next hop which may not be its parent in this case. At last, yes , a packet can be sent to its parent in this case. With my Xbee, I do not have enough tool to see how a packet is sent.


(Tony Fleisher) #317

Further investigation found that I maybe seeing similar problem to what @jpoconn87 was seeing. I have one sensor (newer battery ready version) that will apparently only communicate with the network if another sensor (one of the older models) is connected. Even after reset, it could only be found by the hub search after I plugged the other sensor in.


(Joe ) #318

Yep, that’s what I’ve seen in my network. Multiple resets don’t seem to help. If I remove the device the sensor is tied to, it stops responding until I add the other device again. I’m pretty sure it’s not a permanent situation since I believe the module was tied to an Ikea bulb earlier. I don’t know what I did to break that relationship the last time, but the Ikea bulb isn’t on my ST network anymore so it jumped to the gledopto controller.


(Albin Antony) #319

Hi, I have few Xiaomi Aqara end devices such as the button, motion sensors etc are paired with my coordinator. Due to range issues, I have a repeater to route data from sensors to the coordinator. I am receiving data from sensors in my coordinator via repeater as expected. Everything works fine until the coordinator is turned OFF and then turned ON. Once power failure happens the 64bit source address of sensor in the data packet that I received in coordinator appeares to be changed

Data received from Xiaomi Aqara ZigBee sensor at coordinator end before the coordinator was turned OFF is as follows

Explicit RX Indicator (API 1)

    7E 00 19 91 00 15 8D 00 02 B8 4D AA BF 50 01 01 00 06 01 04 00 18 10 0A 00 00 10 00 BD
    Start delimiter: 7E
    Length: 00 19 (25)
    Frame type: 91 (Explicit RX Indicator)
    64-bit source address: 00 15 8D 00 02 B8 4D AA
    16-bit source address: BF 50
    Source endpoint: 01
    Destination endpoint: 01
    Cluster ID: 00 06
    Profile ID: 01 04
    Receive options: 00
    RF data: 18 10 0A 00 00 10 00
    Checksum: BD

And data received after turning OFF and On the coordinator is as follows

Explicit RX Indicator (API 1)

            7E 00 19 91 FF FF FF FF FF FF FF FF BF 50 01 01 00 06 01 04 00 18 16 0A 00 00 10 00 12
            Start delimiter: 7E
            Length: 00 19 (25)
            Frame type: 91 (Explicit RX Indicator)
            64-bit source address: FF FF FF FF FF FF FF FF
            16-bit source : BF 50
            Source endpoint: 01
            Destination endpoint: 01
            Cluster ID: 00 06
            Profile ID: 01 04
            Receive options: 00
            RF data: 18 16 0A 00 00 10 00
            Checksum: 12

Here you can see the 64bit source address has changed after turning the coordinator Off and On. If reset is done one or two times after this incident then sensors give correct 64bit source address in data.

My coordinator and repeater are Xbee S2C. Why my 64bit source address has changed.?


(Robert M) #320

What do you mean with “MAC ID”? Zigbee devices have what ST calls a “Zigbee ID” (64-bit MAC address set at the factory that will never change) and what ST calls the “Device Network ID” or DNI. The DNI is assigned by the coordinator (ST) and may change if the device leaves and rejoins the network. If that’s all that’s happening, that alone isn’t a problem, though I’m not sure I’ve ever seen that happen unless I reset the Xiaomi device. In either case, as long as you joined it through ST via the “normal” Zigbee processes instead of using the “catchall” method, from what I’ve seen, it should just update the DNI and properly assign the newly-reset device back to its original/existing device in ST.

If your Xiaomi devices are falling off the Zigbee network, the problem is often an “incompatible” repeater. The Environment Sensor device that is the subject of this thread is one that is known to play nicely with them. The newer version, above, even has a battery backup that should avoid the “power loss” problem that might cause problems with Xiaomi devices if they miss a checkin. Other known compatible repeaters include an Xbee and the new Ikea Tradfri outlets. Many others have been tested and determined to not play well with Xiaomi devices, though I think the behavior of many others is also unknown. You did not say what ones you were using, but that is one thing I would check. You can find more in a couple other threads on this forum if you search on the topic.


(Iman Haryadi) #321

@Albin_Antony, Zigbee Has 16bit Address and 64bit Address.

The 64bit Address sometime is called mac address. It should not change. Some MCU has hard coded area that stamp this mac address. Some has capability to overlay it with another mac. These are typically done during the MCU is flashed. They do not change during the use of the sensor.

The 16bit zibeee address can change. If you pair and unpair, the zigbee it will change. If you have conflict and the sensor has conflict resolution implemented in the sensor, this 16bit address can change for the sensor.

If a sensor dropped out of a mesh (because repeater is down for any reason) and does what zigbee called “rejoin” to another repeater or the coordinator or the same repeater at later time, I do not know whether a new 16 bit address will be given. I have not paid attention for this case. If I have to guess, in this case, your 16bit address should never change.


(Albin Antony) #322

The 64bit source address appears to be changed in my case. And I’m sorry there was a typo in my question. Actually, its the coordinator that was turned Off and On, not the repeater.
Data received from Xiaomi Aqara ZigBee button at coordinator end before the coordinator was turned OFF is as follows

Explicit RX Indicator (API 1)

    7E 00 19 91 00 15 8D 00 02 B8 4D AA BF 50 01 01 00 06 01 04 00 18 10 0A 00 00 10 00 BD

    Start delimiter: 7E

    Length: 00 19 (25)

    Frame type: 91 (Explicit RX Indicator)

    64-bit source address: 00 15 8D 00 02 B8 4D AA

    16-bit source address: BF 50

    Source endpoint: 01

    Destination endpoint: 01

    Cluster ID: 00 06

    Profile ID: 01 04

    Receive options: 00

    RF data: 18 10 0A 00 00 10 00

    Checksum: BD

And data received after turning OFF and On the coordinator is as follows

Explicit RX Indicator (API 1)

      7E 00 19 91 FF FF FF FF FF FF FF FF BF 50 01 01 00 06 01 04 00 18 16 0A 00 00 10 00 12
            Start delimiter: 7E
            Length: 00 19 (25)
            Frame type: 91 (Explicit RX Indicator)
            64-bit source address: FF FF FF FF FF FF FF FF
            16-bit source : BF 50
            Source endpoint: 01
            Destination endpoint: 01
            Cluster ID: 00 06
            Profile ID: 01 04
            Receive options: 00
            RF data: 18 16 0A 00 00 10 00
            Checksum: 12

Here you can see the 64bit source address has changed after turning the coordinator Off and On. My coordinator and repeater are Xbee S2C.