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
I want to thank you for your great work with the binding here! It´s THE reason, why I chose openHAB vs iobroker - where I was not able to get free@home running (after investing hours in modbus programming). documentation and support here are really excellent too, so thank you!
I just want to contribute one small error, which I managed to circumvent for myself - so I have no hard time with it, but maybe you can solve it and that helps to make the binding even better.
There is something wrong with the scanning of things concerning scenes, which are not manually set up but created automatically. All of my manually created scenes (eg. freeathome:scene:6072d2dca8:FFFF48000001 ) but none of my automatical created scenes (eg All lights Off, or all rollers down) were found as things ( I am sure they have a different address, but I was not able to find it or get near to it).
so I just manually programmed the scenes in F@H App again - and those scenes were found with the binding with no problems.
Strange, haven’t heard about this issue before. All scenes created within F@H should be discovered automatically, as the binding is set to recognise the ‘4800’ part. There is a known issue though, that scenes could be detected both as scene and as virtual switch when doing a full system scan.
Yes , very strange: Because all of the manually generated scenes have a consecutive number (until now: FFFF48000001 to FFFF4800000E; no number ommited, all 14 manual scenes recognised). I programmed those scenes mixed - one time manually, one time automated, after another. so if the automated scenes had the same range (4800), there should be “holes” in the row (01 - 0E, for the automated scenes) or all scenes should have been recognised.
I took a look in the things inbox - no virtual switches detected after another full scan. Could easily have been the other way round, but nothing there (beacause I don´t want to rebuild each and every light switch in openhab - just the most used things, like scenes and raffstore-groups etc. Therefore there are 170 things still in the inbox )
Have you tried enabling dummy things (under bridge settings)? Then all your things as registerred within your Sysap will be autodiscovered, and you would be able to idenitfy your scenes, and see if your scenes potentially are discovered as “dummy”.
As mentioned, the binding is set up to get a full device list from sysap during scan, and based on the parsed deviceTypeId, the correct thing type is created automatically within OH (FFFF4800 being the id recognised as scenes).
Hey! Thanks for the tip - it was totally correct! I only had to reboot after toggling the dummy - but then it worked fine: I discovered a bunch of dummy items which are the “missing” scenes. (furthermore some dummy “notification actors” - they trigger scenes from automization within FreeHome, e.g. when illumination is > 50000 lux -> rollershutter down - maybe this will be useful either later on…!)
I tried to create a thing out of the dummy (which was possible) - but then, creating an item, had no functionality (the only channel was “text”).
the dummy has the name e.g.: freeathome:dummy:6072d2dca8:FFFF48030002 (resp.: 48030001, 2, 3 and so on). Do you have an idea resp would you be so kind, to give me guidance on how to change the dummy in a “normal scene”? (…and do you use these notification actors?)
Notification actors are not possible to use with the binding. Only regular scenes created from sysap, i.e. recognised as triggering on/off switch. Also, dummy things are set up with no function, just used to identify things.
For notification actors, you either need to let them remain as is in your F@H setup, or you would need to convert them to OH rules to have them implemented in OH.
Based on your input, stating that your scenes are recognised as FFFF4803… I do not understand why you don’t get them recognised as scenes. The binding autodiscovers scenes based on text containing ‘FFFF’ or ‘4800’. Which version of the binding are you using?
Hi everyone,
first a big thank you for your work on this binding.
I need a info for “dummys”:
I have added my free@home installation in OH3 via this binding.
What would happend if i put an updatet .jar file in addon folder ?
Would i have to added all things again in OH3?
Or is a official release as OH3 binding planed ?
Hi, thanks for the great binding @kjoglums . I am on 3.1.0.jar and OpenHAB3, SysAP 2.6.1.
I would like to help with device IDs also, I get most devices detected as Dummys only. Notably RollerShutter 1.1 and 2.1 devices , Sensor 2.0 devices, Sensor/Switches 2.2 and 2.1 … all get detected as Dummy and Code 2039 - any idea and how can I help fixing this?
