Another user told me that it is working for him, too. And he thinks that there is no signal coming back from openhab, that the Switch was set to ON/OFF. So the switch jumps back in the state that was set before.
Is there a simple solution to give back a feedback to f@h via the binding or openhab, that the switch was set to OFF or ON?
Virtual switches work both ways, sending commands / reading updates via websocket. Meaning, sending commands will work both from F@H as well as OH. Also, OH should read updates and update itself whenever (from whatever device) the virtual switch is triggered.
Scenes, as created from F@H though, will not be read by OH, as F@H scenes are not sending updates over websocket.
I found very good contribution the binding from @kjoglums. But unfortunately with my setup with only wireless devices I had many troubles. Therefore I created in the last weeks a free@home binding based on the official local API from Busch-Jaeger/ABB. The binding is REST for setting the values and the updates are running via Websocket.
If somebody interested I could like to provide the binding or share the source code.
However it is supporting currently only the switch-actuator and thermostat, because I have only these devices, but they are working stable in my test environment. I plan to add the dimmer and scene devices in the next days.
However some devices types will be still missing in my implementation, therefore I would like to ask your support to be able to implement the other devices as well. It would be a great help, if somebody could provide me a ādevice_listā from sagger.
and at last but not leat I would to say thank you to @kjoglums, his implementation gave a lots of ideas for the implementation.
Hi @UhA what a great achievement! I would be really interested in testing your new binding based on local API and also to support you with device list and config
Hi,
you can find the compiled binary on the GitHub in the target folder. Regarding the device list files, I sent you a private message with a link where you can upload the device list files
Thx
first I want to say āThank youā to Stian to provide the binding also for OH 3. Great work.
I have to write here once more about my problem with the XMPP-streams in my syslog and daemon.log under /var/log.
I thought, this might be my hardware or software problems. But I just bought a new Raspberry 4 and installed OH 3.0.1 (via OpenHabian) and Stianās Free@Home-Binding for version 3.0.x, which is now working. But also on this installation, my system logs are full of these XMPP-streams. After a while, my ZRAM disk gets 100% full and no more log is written. When I delete daemon.log for example, then I have once more free storage.
Can anybody else also see this issue? You just have to connect to SSH server and enter ātail /var/log/syslogā . Then the last 10 entries are shown.
āFeb 3 13:04:01 openhabian karaf[684]: IN (tinyxmppd696107): <message id=āstz832219ā from="mrha@busch-jaeger.deā to="installer@busch-jaeger.de" ā¦"
Where can I switch off this logging? I think, itās anywhere in the XMPP-program, but I cannot find it. @kjoglums: Which XMPP-program do you use here? Can I find the source-code anywhere? Maybe I find out, how to switch off. Poorly, Iām not so good in programming issues. Will be great if anybody can help me.
I have identified the issue, although uncertain what would be the best approach to eliminate the problem. As part of bridge initialisation, i.e. establishing the XMPP session (using the XMPP.rocks library), a ConsoleDebugger (which use System.out) is implemented to debug the handshake/stream initialisation process (code shown below).
So, the intention of the ConsoleDebugger is to be able to troubleshoot failing bridge connects/stream initialisation, although seem all stanzas are logged. And even if not implementing av ConsoleDebugger as part of the binding bridge initialisation, the XMPP.rocks library will create one by default.
Could try setting the debugger to null for the binding code, but would then lose default XMPP debugging. Could still work, as the binding also is set up with additional debugging for incoming stanzas, although, not for the outgoing stanzas as part of the handshake/stream initialisation.
Hi,
thanks for very fast analysis.
With set the debugger to null, you mean log:set null org.openhab.binding.freeathome in karaf-console, do you?
Will it be anyway possible to filter out these entries to syslog / daemon.log? I checked it within the rsyslog-config. But Iām not familiar with it. Donāt know, which process I have to exclude.
Do you also see the entries in syslog? How do you handle it? Iām always running out of storage
I see some entries in syslog (running openHabian on RPi 3b+, SSD), but I havenāt (and still donāt) consider them as an issue/concern.
Unaware of options/config to exclude/filter certain entries from karaf console, so setting ConsoleDebugger as null would be a binding code alteration. However, this would break the debugging if/when required for troubleshooting handshake/stream negotiation.
Is it possible to configure it anyway by a parameter which donāt have to be set hard-coded? Iām thinking of a debug switch within the bridge-setting dialogue or maybe, donāt know if it works, by setting the log-level of the binding.
Maybe itās a good possibility to have a stable running system and having a opportunity to debug it.
The XMPP traffic logging (Console Debugger) is set active as default, but toggling button OFF or adding yaml code as shown below and restarting binding will stop console logging. In fact, it appears as the issue of having to reboot OH as part of starting up the binding is gone when deactivating Console Debugger.
@kjoglums thanks for the binding.
Iām interestend in testing it. where do I have to copy the jar file?
//usr/share/openhab/addons did not work for me.
Do I just have to copy the file in the folder and reboot? Is the binding supposed to appear in the bindings list then?
Iām quite new in OpenHAB.
You could download the latest version from Link, and put the jar file in the addons folder.
From Main UI, choose Settings / Things. Then hit the ā+ā sign (lower right corner), and choose the Free@Home Binding. Then select Free@Home Bridge and configure based on SysAp IP address, username/password (need to be an āinstaller accountā).
Once you get the Bridge online, you can repeat the sequence Settings / Things and hitting ā+ā, and you will be able to scan for the things in the F@H system.
Hello Stian ā¦ thanks a lot for adding this debug-switch to the binding. Now, everything seems to be quiet in the logs
Like you wrote, I have to restart OH.
@fl0kay : The binding wonāt be shown in the binding list āsettings/addons/bindingā ā¦ But itās available in OH, when you keep to the description of Stian in the previous post
has anyone tested to run the free@home binding with openhab 3 in a docker ? It drives my crazy ā¦ In OH 2 everything works fine. In OH3 I can not connect to the bridge.
First everthing started with initializing and stopped there, now I got an communication error xmpp connection loss. Even I am neither an beginner nor expert with openhab I have no clue what to check an to do. Has anyone an advise ?
Is it possible that I screw the local api by creating an ssl certificate in the app.
Hope someone can help me.
Thx
Sebastian
ok I found the mistake. My password was to complex. You schould not use special signs. However I just saw at the Busch JƤger Hompeage that there is a now Hotfiix V2.6.1 out there, which should fix the problem. It cost my only 2 month of trying in my free time to figure that out so I just want to let you know