Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
mqtt_for_digitalstrom [29.01.2018 10:01] – [MQTT for digitalSTROM] Pascal Suter | mqtt_for_digitalstrom [29.01.2018 10:08] (current) – [the script] Pascal Suter | ||
---|---|---|---|
Line 5: | Line 5: | ||
* thanks to the DSS's web-interface, | * thanks to the DSS's web-interface, | ||
* 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. | ||
Line 15: | Line 15: | ||
===== what I want to add ===== | ===== what I want to add ===== | ||
- | While the existing MQTT bridge is fine for changign | + | While the existing MQTT bridge is fine for changing |
- | luckily there is a nice socket-based API for virtual devices available | + | luckily there is a [[http:// |
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': | + | "value": |
- | 'tag':'${tag}', | + | "tag":"${tag}", |
}` | }` | ||
client.write(JSONaction); | client.write(JSONaction); |