digitalSTROM binding: Feature Request

I would like to have the digitalSTROM-binding to support:

  • UDA items: for the execution of UDA’s (User Defined Action) that are already defined on the digitalstrom server (dss)
  • Blinking channel or scenes: option to make digitalStrom things / groups / zones blink, with support of duration
  • Sessiontoken item: for obtaining the sessiontoken from the dss to use in scripts / rules
  • User Defined States: support for reading the state of User Defined States

It would make this great binding, even greater.


I am not sure, if your feature requests will fit into the design of digitalSTROM API.

UDA items: will check API documentation
Blinking channel or scenes : What would you like to achieve ? Couldn’t this be done within rules ?
Session token item: What is the need for having such an item /channel ?
User Definde States: Could you please explain, what you mean with user defined states ?



First of all: I’m not a programmer, but I will try to give the way I look at it, a way that might be wrong off course.:flushed:

Blinking is a standard scene in digitalSTROM. >> page 71

Having it available in openHAB will reduce UI development time in openHAB a lot, and will keep the openHAB configuration much more transparant in relation to the digitalSTROM configuration ( they will be “the same”). In my opinion this is in line with the openHAB2 design philosophy to make openHAB “as standard as possible” to end-users.

User Defined States
UDS’s are standard functionality of digitalSTROM as from firmware version dSS V1.13.0 release notes.
User Defined States (UDS’s) are a kind of digitalSTROM environment variables/settings that can be created and set by the digitalSTROM user/configurator (dss-app in the configurator). The state of a created UDS can be set by rules in DigitalSTROM and/or by the user in de digitalSTROM UI (smartphone app) , e.g. an UDS with the name Holiday and the states ON HOLIDAY and/or WORKING-MY-ASS-OFF. In a way they are similar to UDA’s but instead of triggering a range of actions, they set a state, which can be used in other rules and scripts on the dSS/dSS-apps, and hopefully in openHAB.

Again, this can be done in openHAB as well, but for the above mentioned reason it will be very nice to have it integrated in the digitalSTROM binding.

Availability of sessiontoken
If the development of the digitalSTROM-binding keeps in pace with the functionality of the digitalSTROM system, there’s no need at all for having the sessiontoken available in the binding.

But if not, when you want to make use of new digitalSTROM functionality that is not not (yet) available in the binding, you will need to code around it in openHAB using the digitalSTROM JSON “api”. To do that you have to get a sessiontoken (60secs valid) everytime. Since (I guess) it is already available in the binding, it can be used in openHAB and reduce coding. In effect: if UDA’s and UDS’s will not be available, I will try to get them through digitalSTROM JSON requests. dSS JSON architecture

I guess all of my feature requests relate to a redundancy discussion: redundant in the binding or redundant code in all of the scripts of openHAB users. Equivalances of UDA’s can be coded in openHAB as well, but a nice interface for this is all ready available on the dSS.

Thanks for explaining Ton.

As blinking is a standard scene, it should already be available within the binding, as it also support scenes

Channel Type ID    Item Type	Description	                                                          supported device type
scene                Switch  	The scene channel allows to call or undo a scene from digitalSTROM.	  Scene

You might need to scan for the scenes.

Regarding UDS’s, I will contact the developers of digitalSTROM binding.

AFAIK, the sessiontoken is bound to a user login or an application token. Therefore it would not be a good idea to publish the sessiotoken used by digitalSTROM binding.

Thanks, Hans-Jörg,

As to: “Blinking” I was not corrrect: it is not a standard scene but it is standard functionality that can be called easily in digitalSTROM. So “blinking” is not an scene that can be set. Perhaps the binding could have functionality for item,s (zones, devices) to send command 's to. AFAIK that’s not possible at the moment.

As to:

Thank you! Please do as well for the UDA’s, the approach will be quite simalar as to UDS’s.