Devices showing up with ff:ff:ff:ff:ff:ff:ff:ff identifiers.

[andydvsn]

Just fired up the script for some testing and found that my Keyfob, Button and PIR are all showing up with ff:ff:ff:ff:ff:ff:ff:ff as their identifier. Only the button is listing itself as available, probably because it was the first to declare the ID.

https://gist.github.com/andydvsn/864414bd6ed09fe0d6dbe5b8b14c486d

[jamesleesaunders]

I too did see this happening every now and then. Couldn’t figure out why. What I did see was if you open x-ctu and look at the discovered network diagram if showed the ff:ff devices as child nodes of the SmartPlug rather than direct association with hub, I don’t know if somehow the SmartPlug is obfuscating the end device address on route as it broadcast it on? This, unfortunately is another one of my unanswered mysteries, but is it great we have this documented in a GitHub issue so at least we can track it and perhaps encourage someone to help us look into it.

[andydvsn]

How have you managed to work around it, or have you not been able to so far? Seems like that’s one of the biggest stumbling blocks right now, because otherwise a rudimentary working system is possible.

I wonder if it’s because I’ve been powering the coordinator off for long periods and in leiu of direct communication, they’ve latched on to the SmartPlugs as routers.

Doesn’t solve the root cause, but I may move the coordinator to my server so that it’s always on, then see if it happens again.

[jamesleesaunders]

Mt 'workaround' was really to only use one or 2 devices at a time (I know not really a scalable solution!). The only other thing I can say is ff:ff:ff:ff:ff:ff:ff:ff is a ZigBee broadcast address but I don't understand why the 'from' address would be this? Unless there is something more fundamentally wrong with the underlying python-xbee code (I doubt it but possible)?

I think possibly doing some more logging on x-ctu may possibly help?

Unfortunately, for now, it is another mystery to solve...

[andydvsn]

Very interesting. I've just watched the network through XCTU and all of the endpoint devices I have are communicating via the SmartPlugs. At the start of the scan the Keyfob was reporting the ff:ff address, while the PIR and Button both reported their correct IDs. I shut down the script and ran some more discovery passes with XCTU, which picked up everything with the correct IDs first time. Re-running the scanning script half an hour later showed me all of the devices, all connected via the SmartPlugs, all with the correct IDs again.

https://i.imgur.com/64sE5lj.png

I have no idea what this might mean, but thought I'd report progress so far!

The AlertMe servers were taken offline just an hour or two ago, so I'll be adding my PowerClamp/MeterReader to this mix this evening. The Safe & Secure system is still live, so I might take the opportunity to check the spare devices I have for the latest firmware (my Alerty app can trigger firmware updates to devices via the web API).

[jamesleesaunders]

One thing we perhaps should try is prevent us sending messages to the ffff address. When we currently ‘discover’ a new device (regardless of address) we attempt to reply to it even if it is this address. Also we use this as the broadcast address. One quick test may be to don’t reply or send to fffff?

[jamesleesaunders]

Hi Andy, hope you are well. Just catching up to see if you have made any progress or discovered anything interesting on the FFFF front? @jrjefferies has just put in a little fix which you may want to pull the latest commit of. It should improve association of new devices. All the best, Jim

[andydvsn]

Hey Jim, been snowed under recently, but the last thing I did discover was that leaving the coordinator on the whole time pretty much removed any sign of FF:FF addresses appearing. I've had the test setup running for the past couple of weeks and none of the devices showed the issue. They also appeared to recover their proper addresses themselves over time - I didn't reboot them.

I've also associated the MeterReader and can reliably monitor home power usage - that's been rock solid stable the last two weeks as well. I'm now in the process of upgrading devices with the Safe & Secure system before they kill that off at the start of December (noticed some SmartPlugs show up as 'Sm\x02rtPlug' for some reason, so looking to see if that's a firmware bug or not) and then I'll have the physical side of things switched.

Hope you're well!

 A.

[andydvsn]

These FF:FF addresses are reappearing. Never get them in the XCTU scan, but they repeatedly pop up in PyAlertMe. As a test I've modded the library to completely ignore them; when I come back tomorrow I'll attempt another scan to see if not responding is helpful in some way.