Share My Creation [IoT] Home Automation MQTT Dispatcher

Hi,

whilst progressing with my Domoticz Home Automation Solution, a new Tool Shed ("Gartenhaus") is in the make. This shed will have several sensors (like TinkerForge Bricks/Bricklets, but also planned an Arduino) connected to a Raspberry Pi running in the shed.
Task
How to transfer sensor data from the shed to the home automation server?
Solution
Data from the TinkerForge Bricks/Bricklets is gathered via MQTT subscribtion, to be published to the Domoticz Server.
A B4J non-ui application (tfdmqttdispatcher) is running on the shed Raspberry Pi to dispatch MQTT messages from TinkerForge to Domoticz.
Two MQTT Clients are defined in the dispatcher, one for TinkerForge to gather data from the bricklets and the other one for publishing the TinkerForge bricklet data to Domoticz.
Communication Summary
Gartenhaus TinkerForge Bricklet > Subscribe TinkerForge MQTT Topics > Convert & Dispatch > Publish Topics to Domoticz Home Automation Server MQTT Gateway > Domoticz Display Sensor.
Status
In testing mode - but running fine. Next is to add more sensors and implement in the shed (build outdoor cases, wiring, power supply via solar panels)

The B4J Application source attached.

Will keep posted on progress.
BTW: Currently 52 Devices (Sensors, Switches) defined on the Domoticz Home Automation Server (a Raspberry Pi B+ which is running since almost 1.5 years without any issues; Several B4J non ui applications run as processes to perform several tasks)

 

[JakeBullet70]

Very nice!!!!! Please keep us informed!

 

[rwblinn]

Update 2016.05.03
Progressing on getting Raspberry Pi information from the Shed Raspberry Pi to the Domoticz Home Automation Raspberry Pi server. A B4Jnon-UI application is obtaining Raspberry Pi status information and published these to Domoticz (see attached soure, folder rpidmqttdispatcher).
The MQTT dispatcher for sending TinkerForge sensor data to Domoticz has been updated (see attached soure, folder tfdmqttdispatcher).
Because of issues with WLAN in the Garden, dispatching is now done via cron jobs running every 5 minutes. This is not the final solution - work in progress to handle network errors in a better way.
Included the readme as well with some additional thoughts (need to polish the file up a bit).

Enjoy reading the source

Domoticz Floorplan Screenshot of with actual data:

Lastest Setup:

 

[JakeBullet70]

Very cool! I am getting ready to add HA to my project. I too am using b4j and MQTT as my connecting glue. Right now I am going to use either
openHAB or Domoticz as the brains. Not quite sure though what would work best. If you have thoughts please let me know.

Again, thanks so mush for sharing!

 

[rwblinn]

Thanks - Good question about openHAB vs Domoticz. I am still going round what is best for the long term.

My experience so far:
Domoticz is easy to setup and maintain (most can be done via web interface) but you have to find your way around as the documentation is not well maintained - lots of trial and error, searching through the Domoticz Forum, ask questions in the hope they get answered. The Domoticz core is maintained by one person with some helpers - could be an issue on the long term. To do scripting, basic Lua knowledge is required. Domoticz runs stable - got it up for 1.5 yrs on a RasPi 2 B+; The api and mqtt features are good. SQLite database which you can easily extract data from. Lots of hardware support, but again need to find your way. Good logging mechanism - important for debugging. Good support for mobile devices. There is no binding concept - which requires full Domoticz update if changes are made by hardware suppliers. Domoticz has a lot of features including Blocky support.

openHAB is difficult to understand when starting - learning curve required. It is easy to define simple devices, but when it comes to more advanced features, then rather complex "Java Like" knowledge required, but also defining items is quite a task plus features like graphs etc. The logging mechanism is using Java type error logging - not easy to get the errors. The addon binding concept supports many hardware devices - which can be used straight. If new hardware or update then simply replace the binding. openHAB has a consortium behind with many developrs, there are loads of documentation and samples available. Gives a more profesional touch.
I am looking more in openHAB these days - but so far sticked to Domoticz because of previous mentioned --- running fine.

 

[JakeBullet70]

Thanks for the information. One thing I did notice was openHAB is JAVA while the other is c++
OK, I think I am going with openHAB.

 

[rwblinn]

Update 2016.07.04
It has been a while since updating, but over the last days making good progress.
Bit of background: Several solutions tried to gather & publish data from the shed: Arduino with RF24 (not enough range, not stable), Raspberry Pi with XBee (range ok, but not stable), ESP8266 NodeMCU (range ok, stable, but the sensors not fit for outdoor, good for experimenting but not for more robust field work) ... means seeking furher for a proper solution.
In July 2016, TinkerForge announced the Master Brick WiFi Extension 2.0 based on the ESP8266 chip - great news.
The WiFi extension is placed on the Master Brick and can be accessed using the standard API methods, no need for a Brick Deamon nor for a Raspberry Pi or Arduino.
A test solution has been build and running fine since.
Next: Implement the Hardware in the shed.

Ways-of-Working
The Gartenhaus Data Dispatcher, B4J application (source attached) runs as a process on the Raspberry Pi.
After start, a connection is made to the TinkerForge Master Brick via WiFi Extension. In case the connection fails, the process retries every 5 seconds.
In case successful connection, a getter is gathering, via timer every 60 seconds, the values from the various Bricklets.
The measured values are converted to MQTT topics and published to Domoticz (payload). Domoticz checks the received payload and updates the device values.

Screenshot of the Domoticz Floorplan for the shed ("Gathenhaus")