I would like to have the digitalSTROM-binding to support:
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 ?
Best
Hans-Jörg
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.
Blinking is a standard scene in digitalSTROM.
http://developer.digitalstrom.org/Architecture/dss-json.pdf >> 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.