For the motion detectors with actuator I managed to do a workaround, as within the F@H web service it is possible to set up a “trigger” along with actual motion detection (switch trigger). So now I have created some events/actions within F@H webservice which creates a trigger on motion which is recognised as the motion switch within the openhab binding.
Meaning I have now successfully implemented rules for my motion detectors (with relay) within OpenHab, even though not having the motion detectors directly wired to any lights.
I’ve updated to Firmware 2.2.4 about 2 days ago.
I got the same Problems as phil2.
Maybe I can support you in reverse engineering:
As soon as I will find time this weekend I’ll look into the “Roller shutting” issue
and try to find out the adresses you mentioned.
i am still on fw 2.1.7 but since some days, some of my blinds do not show any percentage anymore if they are moved via the physical switch of the blind.
i tried to remove the items and readded them.
any idea what could be the problem?
thanks a lot
Sorry for the long period of silence. The f@h binding is still maintained, but as it is a hobby project I could not react more fast.
@kjoglums: thx for investigating the changes that would be necessary to operate with the latest FW. Could you please provide me a pull request or at least a bit hub commit. I will then incorporate the changes to the head and generate a new marketplace package.
I will try to schedule this for the upcoming weekend.
@kjoglums: it would be great if you could beta test the version then.
Yes, this is actually perfectly normal based on code as is.
I have made use of Rocks XMPP library which has an inbuilt websocket connection code. However, as our Busch-Jaeger Free@Home SysAp is following an old websocket connection protocol (compared to Rocks library which is using a more recent protocol, ref IETF), I was in need of modifying the Rocks library to be able to use the code for F@H.
As part of this work/debugging, I introduced log.warn to separate between the opening/binding stream and general stream (between SysAp and OpenHab), whereas general stream is stream acknowledged by the existing Rocks XMPP code. So, the warnings you see are just confirmations of actual stream received from F@H SysAp, which is acknowledged by the code.
Basically, we can remove the log.warn if you find it an annoying feature in the log. For myself I kept it, as I get a continuous verification that the F@H SysAp actually is sending response / updates.
Now when I click on the slicer for the Item Light_OB_barD (which is dimmer) it does nothing
2019-06-06 15:05:54.701 [ome.event.ItemCommandEvent] - Item ‘Light_OB_barD’ received command ON
2019-06-06 15:05:54.766 [nt.ItemStatePredictedEvent] - Light_OB_barD predicted to become ON
2019-06-06 15:05:54.918 [vent.ItemStateChangedEvent] - Light_OB_barD changed from 0 to 100
It seems that the dimmer_fading channel does not support ON / OFF commands? Would it be possible to implement ON/OFF for the dimmer but not in a way that it will set 0 or 100 value, but it will switch the Dimmer unit off using dimmer_switch ? (because I want to be able to switch off the light or ON the light with the latest dimmer value remembered.
@The_Spirit Do you still face this issue? Perhaps you have to recalibrate your raffstores via free@home webinterface. If you login to the f@h sysap and the raffstore icon shows a ?, no update events might be sent.
As I’m not aware how to get the getAll.xml and I haven’t found it, I can’t add it here or on git. If this is required, please let me know to generate it or how to find it. Thanks.
I got the “automatic” update to version 2.3.1, and apparently Busch Jaeger/ABB has made changes to their websocket communication, although not in favour of official websocket protocol nor customized XMPP code which the updated F@H binding is based on. So my OpenHab setup is actually “broken” after the update.
I see a likely solution though. However, my Eclipse / OpenHab setup is outdated, so I do not have the ability to do any corrections / pull requests. So we have do rely on @ruebox to do the actual adjustments.
The issue seems to be related to the ID communicated in the handshake between F@H and OpenHab. As part of the customized XMPP library code, more specifically the ‘XmppWebsocketDecoder’, there is a customized code:
String ID = s.substring(s.indexOf("id")+4, s.indexOf("id")+40);
As I can interpret from the updated BJ/ABB approach, the code should be modified to:
String ID = s.substring(s.indexOf("id")+4, s.indexOf("id")+18);