Is the Subscriber-Publisher pattern applicable also to actuators?

Question

There are tons of tutorials on the web, especially with RabbitMQ, on how to publish sensor data; for example, temperature, humidity, etc. Just publish the value to a message queue and anybody can consume it.

So far so good. But how about actuators?

Let's take a light switch for example. The light switch publishes the current state of the luminaire to a queue. It also subscribes to a second queue to listen for events. This would allow a bidirectional communication. If someone/something wants to turn on the light, an event has to be published to the message queue the light switch is listening to.

I hope you understand the idea. Is this the way to go with actuators? Is there any smarter solution? How about security, thinking on using this for doors for example. Is it possible to publish a open door event from anywhere? How easily can it be hacked?

Answer 1

But how about actuators?

Yes pub-sub pattern is applicable to actuators.

Is this the way to go with actuators?

This is one of the ways to go and this is booming because of many cloud providers like

• AWS IoT as a service support MQTT(over TLS, WebSockets)
• Google's Google Cloud pub-sub messaging service
• Microsoft's IoT Hub with MQTT support

trying to occupy the IoT space to move data from sensors to cloud easily with different approaches and as devices have limited connectivity, power, bandwidth, they need lighter weight protocol like MQTT and such which is pub-sub model based.

What my point here is any device that can sense and has data can use pub-sub but the smart thing comes from the type of implemnatation they are doing. Suppose if you are not using MQTT over some encrypted mechanism(TLS/SSL) , the data can be sniffed.

Is there any smarter solution?

It depends on the application and the constraints the problem has and the so called smarter solution varies as time flies. One more thing to note here is that, having a smarter solution is not the smartest way to go around, because implementation is what matters the most and not the protocol or method you choose.

Is it possible to publish a open door event from anywhere? How easy can it be hacked?

Yes, it is possible to open the door from anywhere by publishing an event but this all depends on the application and authentication you are providing, for example you can make your application subscribing/publishing to topics is only after authentication.

---

Real Case Scenario:

I know a lot of companies who are using this exact model for actuators, recently I worked for a team which is a part of Solar Tracking systems where the solar panels are controlled, monitored using Wireless technologies.

Particularly in that to move/rotate an array of panels according to the sun position and based on different energy optimizing algorithms we use Linear Actuators, in this system we also have a provision to control panels manually from web/mobile dashboards in case of emergencies or any maintenance purposes.

In the above scenario to control actuators Pub-Sub model with authentication/encrytption is used.

Answer 2

How about security, thinking on using this for doors for example. Is it possible to publish a open door event from anywhere? How easy can it be hacked?

According to the documentation RabbitMQ uses TLS/SSL. So security level is as good as these technologies. If you check RabbitMQ- TLS Support here are your examples about using SSL, acquiring server Certificates and so on.

---

Regarding your question about a light switch.

What you have described sounds pretty straight forward. The switch listens (subscribes) the potentional sources that want to switch on or off a luminaire. And also it notifies them about changes in the luminaire's state, so they can know when and how to act.

Answer 3

I think your switch device should be connected to a hub (domotic box, zwave controller,...) which handles all these events, so the switch should be dedicated for low level interaction with objects (zwave,433Mhz,...)

Smart devices are very limited on battery so the less they operate on the network the longer they last.