mqtt_for_digitalstrom

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
mqtt_for_digitalstrom [29.01.2018 09:56] – [Current Stats of this project] Pascal Sutermqtt_for_digitalstrom [29.01.2018 10:08] (current) – [the script] Pascal Suter
Line 1: Line 1:
 ====== MQTT for digitalSTROM ====== ====== MQTT for digitalSTROM ======
 I use [[http://www.digitalstrom.com|digitalSTROM]] at home and at some customers as the main bus system for all things related to light. Here are the main points, why i chose to go with digtialSTROM as opposed to other solutions: I use [[http://www.digitalstrom.com|digitalSTROM]] at home and at some customers as the main bus system for all things related to light. Here are the main points, why i chose to go with digtialSTROM as opposed to other solutions:
-  * DS is relatively open. the digitalSTROM Server (DSS) software is open source and comes with various openly documented API's to extend your setup. One is the DSS API which is good for polling status information about the bus system and the other is the VDC-API which allows to create virtual digtialSTROM devices to control stuff outside of your DS network +  * DS is relatively open. the digitalSTROM Server (DSS) software is open source and comes with [[https://www.digitalstrom.org/allianz/entwickler/developer-resources/system-apis/|various openly documented API's]] to extend your setup. One is the DSS API which is good for polling status information about the bus system and the other is the VDC-API which allows to create virtual digtialSTROM devices to control stuff outside of your DS network 
   * the bus itself does not require any additional cables. DS is perfect to install in an already existing house, where you had conventional electrical cabling so far. no extra bus lines are needed as the whole bus works across a relatively slow but very stable powerline network.    * the bus itself does not require any additional cables. DS is perfect to install in an already existing house, where you had conventional electrical cabling so far. no extra bus lines are needed as the whole bus works across a relatively slow but very stable powerline network. 
   * thanks to the DSS's web-interface, the whole bus system can be programmed very easily and it takes almost no technical knowledge to do so. this means, you are independant of electricians once the system is installed and you can easily re-program scenes, move devices to other rooms etc.    * thanks to the DSS's web-interface, the whole bus system can be programmed very easily and it takes almost no technical knowledge to do so. this means, you are independant of electricians once the system is installed and you can easily re-program scenes, move devices to other rooms etc. 
   * despite the fact, that DS has these api's, uses a built-in web-server and connects to all kinds of devices via TCP/IP it is still very robust. That's due to the fact, that the DSS is not actually required for the pure digitalSTROM components to work together. This means, that even if your DSS crashes (which in my case almost never happened, and if it did it was usually me screwing around in the lower levels of the DSS, where you aren't supposed to change stuff ;)) or if your network fails, your wifi acts up or anything computer related happens, your light switches will still turn your light on and off! you lose all the extra features but at least you and more importantly your wife are not sitting in the dark while you debug what happened ;)    * despite the fact, that DS has these api's, uses a built-in web-server and connects to all kinds of devices via TCP/IP it is still very robust. That's due to the fact, that the DSS is not actually required for the pure digitalSTROM components to work together. This means, that even if your DSS crashes (which in my case almost never happened, and if it did it was usually me screwing around in the lower levels of the DSS, where you aren't supposed to change stuff ;)) or if your network fails, your wifi acts up or anything computer related happens, your light switches will still turn your light on and off! you lose all the extra features but at least you and more importantly your wife are not sitting in the dark while you debug what happened ;) 
-  * while DS isn't as cheap as some wifi-based solutions like [[sonoff] and firends, it is relatively cheap compared to other professional systems like KNX, even though it provides a very similar stability and can be nicely integrated. +  * while DS isn't as cheap as some wifi-based solutions like [[sonoff]] and firends, it is relatively cheap compared to other professional systems like KNX, even though it provides a very similar stability and can be nicely integrated. 
   * DS is owned by Hager, a large manufacturer of electrical hardware in europe. So it can be expected that DS will be around for some time as it already has made it into the market.   * DS is owned by Hager, a large manufacturer of electrical hardware in europe. So it can be expected that DS will be around for some time as it already has made it into the market.
  
 ===== current MQTT solution and its downside ===== ===== current MQTT solution and its downside =====
  
-one downside of DS is the lack of MQTT support. Fortunately, Chriss Gross wrote an MQTT bridge which uses the DSS API to publish the status of your DS system on MQTT and it also subscribes to a set of topics so you can interact with your DS. +one downside of DS is the lack of MQTT support. Fortunately, Chriss Gross wrote an [[https://github.com/cgHome/mqtt-dss-bridge|MQTT bridge]] which uses the DSS API to publish the status of your DS system on MQTT and it also subscribes to a set of topics so you can interact with your DS. 
  
 So far so good, but the problem with this MQTT bridge is, that it needs to poll your DSS every few seconds. If you set the interval too low (depends on the size of your installation and hardware-revision of your DSS, in my case i can't go below 1s) it slows down your DSS and has a negative impact on the user experience of the DSS apps and other control methods that use the API or the Web-Interface as well. Your light switches will still work normally though.  So far so good, but the problem with this MQTT bridge is, that it needs to poll your DSS every few seconds. If you set the interval too low (depends on the size of your installation and hardware-revision of your DSS, in my case i can't go below 1s) it slows down your DSS and has a negative impact on the user experience of the DSS apps and other control methods that use the API or the Web-Interface as well. Your light switches will still work normally though. 
  
 ===== what I want to add ===== ===== 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 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]] 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:  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.    * 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 ===== ===== Current Stats of this project =====
Line 159: Line 161:
  JSONaction=`  JSONaction=`
 { {
-'message':'${type}'+"message":"${type}"
-'id':'${id}'+"id":"${id}"
-'value':100, +"value":100, 
-'tag':'${tag}',+"tag":"${tag}",
 }` }`
  client.write(JSONaction);  client.write(JSONaction);
Line 179: Line 181:
  JSONaction=`  JSONaction=`
 { {
-'message':'${type}'+"message":"${type}"
-'id':'${id}'+"id":"${id}"
-'value':${message}, +"value":${message}, 
-'tag':'${tag}',+"tag":"${tag}",
 }` }`
  client.write(JSONaction);  client.write(JSONaction);
  • mqtt_for_digitalstrom.1517216171.txt.gz
  • Last modified: 29.01.2018 09:56
  • by Pascal Suter