Contents
This note shows how it is possible to use smart home devices and a home built unit to make something not so smart. The total result is functional enough, but I feel like I had to wade across the stream for water. It has also turned out to be a report about some (missing?) behaviour of Plejd units.
The missing link
Moved to 261:[Architecture B] on 14Oct2024.
Aside: feedback from Smart Home IoT devices
The fact that Plejd and futurehome are mentioned here is by pure coincidence. Plejd because the user of my Beep-BRRR happened to have it. Futurehome because a friend that dropped by happened to have it.
Disclaimer. If the standards do not define any requirement of error handling of the sort I go through in this chapter, for the these systems, this chapter is only interesting. But in my opinion, still very interesting.
Plejd
I bought a Plejd GWY-01 since the «must have» factor was too high. This is cabled to the internet router and it then talks with the other units for me over Bluetooth radio when I’m away, instead of Bluetooth directly from the phone. It even has a softblinking LED, just like Apple started with on their iBook (I think) and I personally added to some AVR / ATMega based units at work in the early two thousands.
With my background I was after some testing.
(1) I placed an SPR-01 and lamp pair in one window, close to the GWY-01and went outside the house. When the app told it was connected over the gateway I switched the lamp on and off. Worked, no failures. On and off and on again, many times. On meant on and off meant off.
(2) When I moved the pair to the other side of the wooden house, far from the gateway, but close enough, the lamp went on and off. The data sheet says 10m for Bluetooth, it was about that. Still on meant on and off meant off. But probably since this was on the range limit, sometimes it quietly failed. So I wanted to test more.
(3) I then shielded the SPR-01 with a kettle, the switch in the app went on, but the pair did not. On meant staying off. After three minutes there was no error message in the app. When I removed the kettle it didn’t come on, either. On meant not even trying.
This is surprising, if you ask me. I who have worked with safety critical applications for a full professional life, and related to IEC 61508 for so many years. Plejd hasn’t said that this is a safety critical product, so they have their word. But not my confidence. Adding an error message should be possible. Especially if the protocol between the app and the gateway has error handling already. If not, they absolutely need to add it. [3] states that «BLE mesh supports transmission of unacknowledged and acknowledged messages at the model related layer.» So I have queried Plejd about this. To perhaps have my confidence restored. Their products are simply too nice to have «features» like this. The good thing for them is that the GWY-01 has wired remote update functionality. (If the units have over-the-air (OTA) update, then I assume that [2] is never able to happen.)
(4) Then I tested another situation where the App is connected via Bluetooth since the push button WPH-01 is on. No, that doesn’t matter, if I put the WPH-01 inside a double metallic box (so that even 2.4 GHz won’t slide out), same behaviour – the app still says that it’s connected via Bluetooth. The gateway is on, but the SPR-01 is not powered and WPH-01 is not seen. Also this gives no error info nor does it take the slider indicating button back again, when I try to switch the SPR-01 on. There is a short-lived checkbox appearing. Nice, but with misleading info. Even if the excuse may be that since I know that the SPR-01 is unpowered then there correctly is no visual feedback, since the lamp is still off. But still on means off.
(5) If all my three units are off the app correctly says that it cannot reach the gateway. In that case trying to switch SPR-01 is not possible, an ‘x’ appears for some time, and the slider stays off. In that case not on means off (correct).
Plejd certainly have filled in some of the cells in the error matrix, but there seems to be quite some white land left.
I do recognise (but with a «hmm..») the conflicting behaviour or the push button being the master (with visual feedback only) and the app being the master. But where the push button would not care about acknowledgements the gateway and the app should. In my opinion.
(I may here have taken the role of some odd(?) classification approval person, as I would remember them from work. Sorry, Plejd, but it was too tempting.)
As of 24Apr2024: GWY-01 version 4.9.7 (latest). SPR-01 version 1.0.15. The app version iOS, 5.3.0.0.20. (WPH-1 version 0.5.0).
futurehome
I have not bought or tested the products from futurehome [4]. These are based on Zigbee or Z-Wave radio, ie. non-Bluetooth to put it that way. Both handle mesh topology. Zigbee works on «Bluetooth and Wi-Fi bands» around 2.4 GHz, while Z-wave does around 900 MHz. Speed vs. range make up some of the differences.
Disclaimer: this [paragraph] is rather rudimentary. Don’t depend on it for evaluation purposes! Futurehome EH support has been super and patient, but blame me for the inaccuracies or perhaps even errors! [They use a protocol called FIMP – Futurehome IoT Messaging Protocol (Well documented here. It is based on MQTT) to communicate between the internal tasks, both on the Smarthub and on the IoT devices. Zigbee or Z-Wave takes care of the radio, which then carries FIMP contents in some way. So there indeed is two-way contact with the IoT devices. However, to which degree failed actions extend to error messages or status updates depend on the usage. From the app, when doing individual actions, yes. Doing actions in automation groups or modus changes however: kind of. There is a retry function and a work pool to pick not done actions for the time when the connections may be up again, which may end in a final «signal problem» should this fail. One might have to be there to observe which of the actions that happen. «Hmm..» However, there is some kind of scripting possibility for individual users to extend this functionality, even into full reporting. Connection with the cloud server both from the Smarthub and the mobile app probably are over TCP/IP, carrying some proprietary protocol. Smarthub runs linux, and the units use some proprietary runtime.]
Others
I have not studied whether these are usable or whether they would do the missing error reporting, missing from Plejd. The links are just for some, but not full references:
- Nexa Bridge (Clas Ohlson)
- eve (Eplehuset)
- TellStick / Telldus
- Proove
References
Wiki-refs: AVR microcontrollers, Bluetooth mesh networking BLE mesh, Galvanic isolation, IEC 61508, International Association of Classification Societies, IP code, MQTT, Over-the-air update OTA, TCP/IP, Zigbee, Z-Wave
[1] Plejd, see https://www.plejd.com
[2] IoT Goes Nuclear: Creating a ZigBee Chain Reaction by Eyal Ronen, Colin O’Flynn, Adi Shamir and Achi-Or Weingarten, 2017 IEEE Symposium on Security and Privacy. Read at https://ieeexplore.ieee.org/document/7958578 (Early Philips Hue smart lamps)
[3] Bluetooth Mesh Analysis, Issues, and Challenges by ÁNGELA HERNÁNDEZ-SOLANA, DAVID PÉREZ-DÍAZ-DE-CERIO, MARIO GARCÍA-LOZANO, ANTONIO VALDOVINOS BARDAJÍ, and JOSÉ-LUIS VALENZUELA. In IEEE Access (2020). Reead at https://ieeexplore.ieee.org/document/9035389
[4] Futurehome, see https://www.futurehome.io/en/technology, (Forum)