Is there anyone using MQTT as gateway for connecting to openHab running on another Rpi. If so please help with any links, post or any information to direct me on the right path.
Hi @edoardoo
I actually stumbled on your post a couple of weeks ago! Great writeup!
We certainly need contributors. We need help with everything from the visualisation of sensordata in the frontend (considering using d3.js) to mqtt/node.js backend for receiving and processing sensor data.
Please contact me or Johan for further discussions.
@gregl I have used this procedure a few times:
Define for example a V_VAR1 message for the query (or use any other suitable message type depending on purpose),
Make a MQTT binding for this message i Openhab (for example bind it to a switch, a number or whatever fits the purpose)
Make a rule in Openhab that reacts on this incoming message ("When Item xxxxx received update then ......)
Fix whatever logic is needed in this rule so you can send the queried info back to the sensor. If no existing binding is suitable you can of course define a V_VAR2 message (or use other type which fits) for the return message.
In the "Incomingmessage" function use whatever logic is needed to decode the returned message.
Reason for choosing a custom type of message (like a V_VAR2) for sending the info back is of course that it is easy to sort it out from the stream entering the incoming messages function. If you have no other incoming messages or the logic for the queried info already is in place then you do not have to think about this.
Hope the explanation is understandable, if not please revert.
Cool project @bsmtdweller
New thread or stay in this doesn't matter much, but for people searching the forum (or their favorite search engine) in the future, I think a new thread with a subject containing "incubator" will be more clear.
I would build it with multiple nodes. Smaller chunks of code, easier wiring, easier to isolate individual parts which helps tremendously when troubleshooting, easer to reuse code for one node in case you (or someone else) want to expand the project later, easier to remove a part if you (or someone else) don't need it.
The non-mysensors code is more important, so I would start with that, but make sure all parameters that you want to be able to change are stored in variables and not hardcoded. Then add the MySensors code to update the values of the variables.
The autonomy will be hard. Normally I would prefer to have all logic in the controller, since a controller has much better ways to program and debug stuff. Not fun to write - and maintain - in C with very rudamentary debugging tools. But as you say, being reliant on having Domoticz working all the time might not be good. Having the system fail gracefully will be a challenge. A start could be to search the forum for MY_TRANSPORT_WAIT_READY_MS to see what others have done. And maybe - to make the system as reliable as possible - you should add everything to a single node instead of splitting it up into multiple nodes.
Okay, finally got the original nrf24l01 SMD modules with the square chip visible... As exptected, things work just fine now, so the culprit of my issues was really the incompatible/fake "nrf24l01" SMD modules with the epoxy blob. If you want to use normal nrf24l01+ modules together with this smd gateway, DO
NOT USE the smd module with the epoxy blob, as they won't work.
Using only the fake SMD modules might work, too, but mixing the fake modules with real ones does not work.
