<< Previous |
New questions and solutions
As I start thinking about integration with connected appliances in more details I realized that I havent address yet the following challenges.
1. How communicate to any MQTT connected device, that can understand switch off/on commands?
There is no standards for MQTT topics in IoT space. There are best practices for topics naming, but it is not necessary followed.
Sonoff devices are not following these recommendations. So to turn off Sonoff device the following topic and command should be used: cmnd/sonoff/power off.
I've defined my topic structure as been described in one of my previous blogs [Upcycle It] WiFi Connected Smoke Detector #3: Connecting dots - MQTT + Node.js + Slack based on best practices.
So, a command to turn off socket 1 of PDU in a workshop will look like:
workshop/appliance/pdu-socket1/power off
A command to turn off outlet 1 in a workshop will be:
workshop/appliance/outlet1/power off
It is clear that a translator is required to map them.
Upcycle topic/command | Sonoff topic/command |
---|---|
workshop/appliance/outlet1/power off | cmnd/sonoff/power1 off |
2. How to publish command to multiple connected appliances/sockets/outlets?
MQTT publication doesn't supports wildcards. Wildcards only supported for subscriptions. It means that a command to switch off power should be published to different topics for a different connected devices. should listen to a generic command for the location.
My approach to this challenge is to split it in two parts. I've defined a special appliance id - all. So to substitute a wildcard gap in MQTT publication I can just publish a command to all appliances workshop/appliance/all/power off . It only helps partially as most of the appliances will not be smart enough to listen to several topics for a command. So the second part of the solution is to map one incoming publication to many predefined topics, so we can control several appliances. In addition, it possible that someone would like to switch lights on to support evacuation process as been suggested by rhe123 .
Upcycle topic/command | Sonoff topic/command |
---|---|
workshop/appliance/all/power off | cmnd/sonoff/power1 off |
cmnd/sonoff/power2 off | |
cmnd/sonoff/light on |
Mapping and translation will not be required in all cases. So I've decided to make it as a separate optional process "Publication Translation Processing".
This approach for integration now need to be confirmed with jasonwier92, so we can have an integrated solution.
Translation and Mapping decision
Now I need to decide to keep it simple and just code mapping/translation or find library that already implemented these capabilities.
I've looked briefly and found the following Node.js projects, that can satisfy these requirements:
Decision table and BizRez Rules . Both projects haven't been updated for at least a year and have no collaborators besides their authors.
Next step is to try them and see if they really simplify solution by externalizing mapping and translation in configuration file or make solution more complex to maintain.
Top Comments