I’m implementing a binding for Somfy RTS shutters, based on the CUL transport (I’ve developed the CULFW support for sending RTS commands).
However, this protocol uses a rolling code that changes with each command sent.
I’m wondering if it is possible to store this persistent data for each defined item in openHAB.
In other words: when defining the item, I want to be able to set an initial rolling code value, and this should get updated and saved automatically by the binding.
I have looked at the other bindings, but have not seen someone doing this.
Is this possible? Is it even the correct approach?
Take a look at the Ecobee and Nest bindings, which use Java Preferences to store and retrieve persistent tokens for API authorization. I had initially attempted to use OSGi ConfigAdminManager for this purpose, but OH 1.x depends on -Dosgi.clean=true on every openhab restart, so I reverted to the Java Preferences API, which works well.
I am working on a binding for the panStamp Arduino RF modules. It makes a lot of sense to persist some of the information learnt from the modules (notably their product type code) between restarts. My solution is to create a directory under etc (etc/panstamp/cache) and store and load the information from there.
I’m not sure if my solution is acceptable - if somebody like @Kai can comment as to what is considered best practise, I’d appreciate it.
I believe your solution of storing cached configuration information under etc would be acceptable. The Z-Wave binding does something similar in etc/zwave. For a smaller requirement like storing tokens, I recommend the Java Preferences approach.
Consider that OH1.x is approaching end of life, and thinking about best practices in OH2.x is a good idea.
I’m afraid not, I did not have the time to start developing the binding yet.
I do have a fork of the openHAB2-Repo where I intend to push my binding to (see Github).
I do have some code for openHAB (1), but have never tested it thoroughly, and I don’t plan on maintaining it, since openHAB2 seems to be quite usable already.
Regards,
Thomas
PS: I will post here, as soon as there is something to try out.
I am planning on getting Somfy RTS motors, but can you in any way tell me which ones will be compatible with the binding? Will anything do as long as there’s RTS in the model name? Thanks a lot for any feedback.
I know about the repository - Oliver approached me and offered to create a basic binding skeleton.
Although this is still based on openHAB 1, it should work on openHAB 2 using the compatibility layer.
We have not started implementing anything yet.
Concerning the motors: I don’t know if RTS is the only indicator, but Somfy nowadays has lots of motors using io-homecontrol - a protocol that is not yet decoded, and will not be supported by our binding.
So please make sure that you don’t by any io-homecontrol hardware.
It is implemented as an OpenHab 2 Pluign with a CUL binding and stores the rolling code (and address) in the userdata folder.
There are still a lot of missing parts (e.g. programming the shutters, proper error checking when writing to the serial port, support for percentage of UP and DOWN, …) but at least my shutters go UP and DOWN
hmm, is creating files under userdata really the recommended option? Can’t I use mapdb or other persistence service to manage the data? I’m developing the Rachio Sprinkler controller binding and what to provide access to various setup information per device and per zone. If the binding is able to store them in mapdb a rule can easily get access to that information. Does anyone know how to integrate persistence services in a binding?
