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?
You can for sure put a different jar file version in the add-on folder without having to recreate your things. Just ensure to stop OH before replacing jar file, and do a cache clean before starting OH again with the new jar file.
â2039â is currently not supported by the binding auto discovery. Would assume this would be some wireless devices?
Have a look at Link to see what would be required to get the devices implemented, i.e. a list with full device names (as retrieved from inbox discovery) as well as channels the devices are operating under.
Thanks. What I am confused about - all get detected as 2039 - but they are very different devices, as listed - indeed, all are Free@home wireless - would we need more than ID â2039â to detect them, as behind that ID shown we get RollerShutter 2.1, 1.1, Sensor 2.0, Switch 2.1, 2.2 etcâŚ?
Yes, but we have already implemented discovery for âA039â, which also are wireless devices all recognised with the same ID, by defining thing types based also on device type names. Thus, a list as linked to in my previous post would be needed.
Ah interesting - the devices here are the same! (Jalousieaktor 2.1, 1.1, SwitchâŚ) - Did they change the reported Device ID from A039 to 2039? If we want to try that I am happy to run a version that takes a039 == 2039 and see if things get detected ok.
Well, âA039â and â2039â are probably different versions of the same devices. Although, there is no guarantee they work under the same channels (a lot of different device type idâs for the same wired devices as well, not necessarily operating similarly wrt channels and idps/odps).
Regardless, you can test with the jar file below. Your devices should now be discovered as correct devices, but you need to test functionality to see if they operate as intended, as your devices will be defined with same channels and idps/odps as the âA039â devices.
works great, the devices indeed seem to be same just a newer Version.
One Area of improvment : The Aktors that have additional Sensors (e.g. Jalousieaktor 2.1 / Rollershutter 2.1) - The Rollershutter part works out of the box, the additional Sensor / Rocker channels are missing. Would you be able to add them if I help getting the right idp/odp pairings?
Due to the logic of OpenHAB - might we need to detect the sensors separately from the Rollershutter?
I also have a lot of devices where the Actor is used independent of the Sensors, so one device e.g. Switch 2.2 has 2 Actors, 2 Sensors, and the Sensors are not connected to the Sensors in the same device, but a different device - Free@home is great and flexible by allowing that, as actors and sensors are detected as separate devices - maybe we should do the same here in the binding?
Yes, would need channels and idps/odps, and some unique identifier to be able to implement auto discovery. You could also create manual things for the additional sensors.
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!