Iâve found one issue or inconsistency with the new version of the binding. I have some raffstores grpuped together in the freeathome sys ap configuration (i.e. one physical switch controls 2 raffstores in parallel). PaperUI correctly identifies these groups (e.g. device ID starts with âFFFFâŠâ rather than âABB2âŠâ). These groups respond correctly to âUPâ and âDOWNâ commands (channel âcompleteâ) just like single raffstores, but they do not respond to any values sent to the channel âpercentageshutterâ. Just no reaction at allâŠ?
ABB is using âFFFFâŠâ as device type ID for both scenes, actions, time programs etc created within SysAp. Thus, due to all potential options, it is hard to generalise the binding to handle all different âFFFFâŠâ device type IDs (a lot of different channels/idps/odps).
However, why donât you use OH to group items and/or create rules? Following OH rules tutorial it should be simple to create a rule for controlling both your raffstores based on activation/deactivation of your switch control.
I checked out the new jar file today. First test with one shutter worked fine.
I replaced now my workaround with the new configuration for 13 shutters. Everything is now online. Expecting sun like today, I will have a large scale test tomorrow.
Thanks for your effort. Let me know in case I can help with development / coding.
BTW: May I ask how large your fee@home system is? I have some strage effects which seem to be an access point bug (happens independent of openhan). I would be happy to discussâŠ
My F@H system consists of 34 wired/bus devices + 25 âotherâ devices (Hue, Sonos, virtual switches etc). I have the âoldâ SysAp version, but have not observed any strange behavior (as I am aware of).
Thanks @kjoglums, in case you would have similar problems, you would know: My configurations consists of 57 wired devices. Key challenge is that when I address 11 shutters up (e.g. after sun protection), sometimes one to three of them do not move upwards. Downwards, everything works.
I have contacted Busch JĂ€ger now, letâs see what they say.
@kjoglums Thanks for all the great work! I tried out your 2.5.8 jar and noticed that my welcome door is not showing up. Is that something thats not implemented yet? If not, is it on the roadmap or are you looking for a contributor?
The Welcome M system is not implemented in the binding as of now.
I also have the Welcome M outdoor video station installed, but havenât identified any beneficial use cases to implement the system into openHAB. Maybe you have some ideas you would share?
As a general update: Have been playing around with development of the Free@Home binding to prepare for openHAB 3.0. As it might seem, I am successfully running the new version of the binding under openHAB 3.0 SNAPSHOT environment (testing only). So, looks promising to be able to have a working binding also after the big OH upgrade.
@kjoglums re video: As far as I know, the video feed canât be accessed via the SysAP. You will need the separate IP Gateway.
My use case is that not only can you have a video feed with Welcome, but also door openers / lights. Those are connected to the touch panel and can be triggered via it or the SysAP. This should then also be available via OpenHAB.
I also have a Busch Jaeger Welcome outdoor system ( button at the door-gateway, door opener ). The system can be accessed via the IP-Gateway. Can this binding be used to control the door opener and let OH do an action once the button at the door-gateway is being pressed ?
As far as I understand from the headline this binding suppports the Free@Home products but is the Welcome supported as well ?
@danilobuerger@Wolfgang_S
As I have my Welcome system only as a doorbell/outdoor video system, without IP-gateway, I have no clue if it is possible to implement the system into the binding.
In order to try to implement the Welcome system in the binding, we would first need to identify device type id (possibly from recognition by binding discovery if having âdummyâ things enabled) in order to be able to define the system as a separate thing in OH. Furthermore, we would need to know which channel(s) and idps/odps which the Welcome system is operating under.
in my case itâs different although I have the IP-gateway I do not have the âbase stationâ of the Welcome system as in hour house we have problems to get the wiring from the IP-gateway to the Welcome system ( screen ) that normally is placed next to the door for communication.
So the deicsion was to use the IP-gateway together with the welcome app.
I assume that the binding normally communicates with the Welcome âbase stationâ which we do not have. The IP-gateway is registered at Busch-Welcome page - not Busch-free@home.
The channel will depend on the setup as you can connect up to 4 (as far as I know) door systems.
I donât use Postman. I know the channel and idp that I need to trigger:
1038 -> ch0010 -> idp0000 send 1 to buzz.
I also have no problem implementing that feature in the binding. Again, thats why I was asking.
On a side note: I find it quite hard to discuss code related matters here, it would be much nicer to have github issues enabled in your repository and continue there. Anyway, I will submit a PR over there.
NOTE: Door opener is currently set up as a regular switch (1/0). From binding side, it will not be auto-reset, although the SysAp will automatically reset/switch off once activated.
