C++ sensor gateway design problem.

[GoRo3]

Hi! As last time you manage to help me a lot with QML question / problem, so i'm encouraged to seek for help again.

I'm writing application as a Hub / Gateway for my homemade Iot devices. For now i have two devices, temperature and humidity sensor, and wall light switch. And here it come trouble...

In app my internal design is that I have base class "Devices" from witch "temperatoreDevice" and "SwitchDevice" inherits. Until now I used only one protocol to communicate with this devices and it's implementation of NRF24l01 radio driver and my custom message parser for receiving radio communication and parsing it to proper device object. Device object's are stored in QVector<Device *> type. But now I want to add a second protocol as example MQTT and I don't have a clue how to implement second protocol connection to my class objects.

For understanding i will show it:

Incoming radio Data----> Radio msg. parser --> Device Manager class ---> View model etc.

But now I want to do:

incoming radio Data---> Radio msg. Parser ---> Device Manager Class ----> View model and MQTT class ---> send data to topic.

and in other way from MQTT to Device manager.

I Was thinking about observer pattern for Devices and connection protocols but In this way i don't know how to serialize this connections to prevent losing them after application restart. And the second problem is that I want to serialize data in SQL database Because MQTT uses topic's for publish and subscribe and I need to save them for objects independent.

My second Idea is to hold all handlers for communication in Devices class but this is ugly and in future when I will implement more protocols it could be very difficult to maintain.

Maybe someone have done such application and will be able to help me?

My Best Regards!

[SGaist]

Hi,

So basically, you want your sensors to store stuff in the database and on each insertion you would like to propagate the value further through MQTT, correct ?

[GoRo3]

Okay, maybe I wasn't precise. I'm looking for some pattern to handle many communication protocols in program and bind them with device objects.

As now i'm receiving data over radio communication and parse it to "Device" object's as temperature sensor or switch(in future much more device types). But now I want to add a another protocol like MQTT. And I don't know how to implement another interface that every device will have option to be able to propagate data over this protocol.
I was thinking about observer pattern and add on demand observers like MQTT class controller or Radio class controller, to device interface and just notify observers to send data over their protocol when device is updated. But this is one direction
What If device need to receive data over protocol? How to connect it to protocol interface?
For example if I put my switch device ON state I can notify MQTT controller to send data over it's interface, but what when some client want to set state as OFF, and sends over MQTT information to device? How to connect it? Observer pattern will not work in this case.
And second question, where to put information about protocol specyfik communication configuration. In MQTT we can subscribe to topic and publish to topic, all devices could have different topic to subscribe and publish. If I put this information in Device interface as QString TopicForTemperature and QString TopicForCommands first I will brake single responsibility principle and second when i add another protocols the Device interface will be full of some different information. I Was thinking to make another layer of abstraction and make base class of MQTTConfiguration and then inherit for example MQTTTemperatureConfiguration and bind object of this class with object of Device in MQTT controller class. Is this good architecture? Maybe i should use different pattern?

[SGaist]

Why not have a central where you collect the data and then have specific "propagetors" that will publish/send/whatever ?

You'll keep your devices focused on getting data and then you can an new propagation channels San you see fit.