Differences

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

--- mqtt_for_digitalstrom [29.01.2018 10:07] – [what I want to add] Pascal Suter
+++ mqtt_for_digitalstrom [06.07.2024 09:51] (current) – Pascal Suter
@@ Line 1: / Line 1: @@
 ====== MQTT for digitalSTROM ======
+**this is me, 6 years later**: i am still using Chriss Gross' gateway and it has been working great for me. Turns out the little delay that i get sometimes when a few lights have to be turned on via mqtt while the rest is directly via digitalstrom doesn't really matter all that much. So there is really no need to write a more responsive gateway as far as I am concerned. There are new gateways out there, which basically use digitalstrom only a as bus and allow other software such as home assistant and similar ones to take complete control over scenes etc, but there have been numerous times in the last 10 years where i was quite happy, that even though my network was messed up or my server had crashed, my digitalstrom lights still could be turned on and only the addons where disfunct, so i am happy to keep it the way it is also in the future.
+i am now migrating the gateway to a new server and with that, it will be [[digitalstrom_mqtt_gateway_in_a_docker_container|running inside a docker container]], since chriss hasn't maintained it since 9 years or so. So you can probably skip the rest of this article and jump straight over to [[digitalstrom_mqtt_gateway_in_a_docker_container]] if you're looking for a quick and dirty solution that seems to work remarkably well :)
+====== old article ======
 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 [[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
@@ Line 13: / Line 18: @@
 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 =====
 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.
@@ Line 161: / Line 165: @@
 					JSONaction=`
 {
-'message':'${type}',
+"message":"${type}",
-'id':'${id}',
+"id":"${id}",
-'value':100,
+"value":100,
-'tag':'${tag}',
+"tag":"${tag}",
 }`
 					client.write(JSONaction);
@@ Line 181: / Line 185: @@
 				JSONaction=`
 {
-'message':'${type}',
+"message":"${type}",
-'id':'${id}',
+"id":"${id}",
-'value':${message},
+"value":${message},
-'tag':'${tag}',
+"tag":"${tag}",
 }`
 				client.write(JSONaction);