Differences

This shows you the differences between two versions of the page.

--- mqtt_for_digitalstrom [29.01.2018 10:03] – [MQTT for digitalSTROM] Pascal Suter
+++ mqtt_for_digitalstrom [29.01.2018 10:08] (current) – [the script] Pascal Suter
@@ Line 15: / Line 15: @@
 ===== what I want to add =====
-While the existing MQTT bridge is fine for changign room states, calling scenes etc, we need something that can enable us to react faster to events that happen on the DS bus. My Idea is, to create an MQTT bridge that connects via the VDC-API to emulate virtual digitalSTROM devices. I could then place a virtual dimmer into a room and set a value of 100% for Scene 1, 75% for Scene 2, 50% for Scene 3, 25% for Scene 4 and of course 0% for off. Now i can publish the value canges for this dimmer via MQTT. The nice thing about this solution is, that the DSS will PUSH status changes to the API and hence to MQTT and we don't need to PULL it as we do with the DSS-API variant.
+While the existing MQTT bridge is fine for changing room states, calling scenes etc, we need something that can enable us to react faster to events that happen on the DS bus. My Idea is, to create an MQTT bridge that connects via the VDC-API to emulate virtual digitalSTROM devices. I could then place a virtual dimmer into a room and set a value of 100% for Scene 1, 75% for Scene 2, 50% for Scene 3, 25% for Scene 4 and of course 0% for off. Now i can publish the value canges for this dimmer via MQTT. The nice thing about this solution is, that the DSS will PUSH status changes to the API and hence to MQTT and we don't need to PULL it as we do with the DSS-API variant.
-luckily there is a nice socket-based API for virtual devices available so we can program a simple node.js script to do that.
+luckily there is a [[http://plan44.ch/opensource/vdcd/?lang=e|nice socket-based API for virtual devices]] available from [[http://plan44.ch|plan44]] a great contributor to the DSS environment. My plan is ot use node.js to implement an MQTT bridge using this api via a vdcd.
 The downsides of this approach are:
@@ Line 25: / Line 25: @@
   * so far the whole solution isn't very stable. when i re-scan the devices on my digitalSTROM bus via the web-interface of the DSS, it will loose the connection to my virtual device. I need to re-start the node.js script to re-connect to the vdcd which provides the API, but as soon as i disconnect the API-Client (my node.js script) the vdcd segfaults. this can of course be solved by simply running it via something like systemd, which whill then simply restart it, but the main issue here is, that my node.js script is not informed, that the connection has been lost by the DSS or that it wants to re-scan all devices. So unless i notice the malfunction personally and fix it manually, my node.js script will not stop and re-initiate the connection.
+The upside, that makes it all worth doing:
+  * NO LAG! which leads to a high WAF (Wife Approval Factor) of the installation :)
 ===== Current Stats of this project =====
@@ Line 159: / Line 161: @@
 					JSONaction=`
 {
-'message':'${type}',
+"message":"${type}",
-'id':'${id}',
+"id":"${id}",
-'value':100,
+"value":100,
-'tag':'${tag}',
+"tag":"${tag}",
 }`
 					client.write(JSONaction);
@@ Line 179: / Line 181: @@
 				JSONaction=`
 {
-'message':'${type}',
+"message":"${type}",
-'id':'${id}',
+"id":"${id}",
-'value':${message},
+"value":${message},
-'tag':'${tag}',
+"tag":"${tag}",
 }`
 				client.write(JSONaction);