You should not be using “Installer” as username, rather a user name which has installer user rights (as shown under the sysap interface).
Under Bridge settings, you could also try to disable Console Debugger.
It would also be useful if you provide relevant log details as part of the “initializing” process.
Again, would be nice to see details from openhab.log. Also, you could try deactivating Console Debugger.
I have testet now with manually window sensor, switch and binär thing.
At least all things/channels works when i switch via postmann the window sensor.
But when i switch in OH3 the window sensor does nothing.
I think the odp channels from the window sensor are unwriteable via OH3, is this possible ?
have anyone a idea or a solution? It doesn’t work again. here are my logs, I don’t have more logs or can I do any thing for more logs @kjoglums? I have AP Update 2.4 OPH3 and Free@Home Binding 3.1 here from the forum. IP Adresse like Web, Installer rights… thx
I see your snip of the events.log. Although, within the openHAB-logs folder, you should also have openhab.log files. As you are running openHABian, you should be reading the openHABian documentation for how the enable samba share, and then be able to read the log files.
Also, using ssh into openHAB, you could set debug logging by log:set debug org.openhab.binding.freeathome to get extended logging features.
Just looking at your snip, referring to CONFIGURATION_ERROR would strongly point in the direction of error related to ip/username/password configuration you are using in your attempt to connect to sysap via OH.
Issues with Virtual Switches (Free@home 2.6.3, openHAB 3.1.0M4)
I have an issue with Virtual Switches in FreeatHome represented in OpenHAB.
Any insights? Thanks.
Olaf
Olaf for me it worked to keep the virtual switches in openHAB but then make a loop of writing the value back on the on off status datapoint in node red. Could work in openHAB as well with a simple rule if you have no feedback loop with other devices
Did you keep ipd/odp at default ? I had to switch them to make it work from openhab, but it still does nothing when the switch is hit in free@home
As I wrote above for first testing keep the iPad ode as they are and make a simple loop in node red or openHAB as a rule: Write back the idp onto the odp
Thanks - I dont quite get it to work ( but almost) - indeed if I copy idp to odp things work (isnt this a bug in the binding for virtual switches that should be fixed? I am on the March version linked in this forum, which seems to be the latest).
As you suggested, I added a node red flow to make that copy. Unfortunately I can not get the flow to trigger correctly to make the copy idp->odp happen: If I activate the virtual actor in free@home (app or web ui), it seems to write idp, but openHAB does not trigger anything thus node red does not trigger the flow . This is the code I used, any hint how to make this flow trigger upon Freeathome web / ui button press would be appreciated, maybe you can share the flow or openhab rule you use for this? Thanks!
[{“id”:“a1cb8e2.0b5677”,“type”:“tab”,“label”:“Klima-Backend ON”,“disabled”:false,“info”:""},{“id”:“41eaf976.4f1328”,“type”:“http request”,“z”:“a1cb8e2.0b5677”,“name”:“Klima SZ VirtAktor ODP”,“method”:“PUT”,“ret”:“txt”,“paytoqs”:“ignore”,“url”:“http://192.168.2.11/fhapi/v1/api/rest/datapoint/00000000-0000-0000-0000-000000000000/6000DF005764.ch0000.odp0000",“tls”:"",“persist”:false,“proxy”:"",“authType”:“basic”,“x”:990,“y”:560,“wires”:[[“249e23f1.0bcd3c”]]},{“id”:“249e23f1.0bcd3c”,“type”:“debug”,“z”:“a1cb8e2.0b5677”,“name”:“Klima”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:1170,“y”:420,“wires”:[]},{“id”:“37a0d1b2.156d1e”,“type”:“change”,“z”:“a1cb8e2.0b5677”,“name”:“Off”,“rules”:[{“t”:“set”,“p”:“payload”,“pt”:“msg”,“to”:“payload[“00000000-0000-0000-0000-000000000000”].values[0]”,“tot”:“msg”}],“action”:"",“property”:"",“from”:"",“to”:"",“reg”:false,“x”:730,“y”:560,“wires”:[[“41eaf976.4f1328”,“d6e43409.85bfb8”]]},{“id”:“d83ceaa5.9b6c48”,“type”:“comment”,“z”:“a1cb8e2.0b5677”,“name”:"Klima via virtuellen Aktor, anderer Workaround für Bug in Virt Switch”,“info”:"",“x”:340,“y”:100,“wires”:[]},{“id”:“eb38deb8.ba453”,“type”:“openhab2-in”,“z”:“a1cb8e2.0b5677”,“name”:“Klima_Schlafzimmer_VirtAktor”,“controller”:“371021da.e89bde”,“itemname”:“KlimaanlageSchlafzimmerVirtSchaltaktor6000DF005764ch0000_Activate”,“x”:180,“y”:540,“wires”:[[“56dc8343.0b3f5c”],[]]},{“id”:“56dc8343.0b3f5c”,“type”:“http request”,“z”:“a1cb8e2.0b5677”,“name”:“Klima SZ VirtAktor IDP”,“method”:“GET”,“ret”:“txt”,“paytoqs”:“ignore”,“url”:“http://192.168.2.11/fhapi/v1/api/rest/datapoint/00000000-0000-0000-0000-000000000000/6000DF005764.ch0000.idp0000",“tls”:"",“persist”:false,“proxy”:"",“authType”:“basic”,“x”:440,“y”:520,“wires”:[[“cb93f5dd.bdf288”]]},{“id”:“d6e43409.85bfb8”,“type”:“debug”,“z”:“a1cb8e2.0b5677”,“name”:"IDP is”,“active”:true,“tosidebar”:true,“console”:false,“tostatus”:false,“complete”:“payload”,“targetType”:“msg”,“statusVal”:"",“statusType”:“auto”,“x”:720,“y”:700,“wires”:[]},{“id”:“cb93f5dd.bdf288”,“type”:“json”,“z”:“a1cb8e2.0b5677”,“name”:“Parse JSON”,“property”:“payload”,“action”:"",“pretty”:false,“x”:690,“y”:340,“wires”:[[“37a0d1b2.156d1e”]]},{“id”:“371021da.e89bde”,“type”:“openhab2-controller”,“name”:“Openhab”,“protocol”:“http”,“host”:“localhost”,“port”:“8080”,“path”:"",“username”:"",“password”:""}]
Uncertain what is the root cause of this, but have been in contact with ABB Developer Team, discussing the virtual switches. For me it is working as intended, using idp0000 to send switch command, reading state/state change from odp0000, without any rules involved to set correct state. I can operate the switch from openHAB (then also getting actual response and state change both within openHAB as well as within F@H). Same goes if I operate the switch from within F@H.
However, in order to achieve this, I needed to modify the F@H config file. See discussion previously in this thread, e.g. Link. Without the modification, as confirmed by ABB, when a virtual switch is triggered within F@H, the virtual switch will continue to send its latest known “F@H” value for each triggering until a differing value is sent via odp0000 externally (e.g. openHAB).
Following the discussion with the ABB Developer Team, the intention of the virtual switch is primarily to get triggered from outside F@H (e.g. openHAB), thus requiring idp0000 for sending command to F@H and also a state confirmation on odp0000, i.e. feeding the switch parameters. For my use case, and how the binding is set up wrt virtual switch, I use virtual switches within F@H (via touch panels) to trigger events outside F@H. Without the modification, I was unable to trigger the virtual switch at all, but after the modification, the virtual switch is working as expected on both sides. The modification of the config file is not recommended by the ABB Developer Team, but I have not received any feedback on how to solve the issue without the modification.
Thanks - will try tomorrow.
This behavior shout actually be default - did ABB say why they don’t recommend it (or why this setting is not the default)? Can you lobby with them in all our name to make this configurable e.g through swagger when creating the virtual actuator, like setting ttl=-1 works today in swagger already ?
Works indeed! (with openHAB and SysAP reboots after installing the edited backup file). Beautiful! Can you ask ABB if we can get a GUI config option for picking the emulation, or at least enable to specify the Emulation when creating the virtual device in Swagger (I tried multiple Syntax options there, but it does not seem to take)
Cheers,
Olaf
I have been in contact with ABB again, and have received a reply: It must be emphasised that using virtualDeviceEmulation is not recommended/supported by ABB, and is done at individual/personal risk.
The reason for the function not being supported/recommended, nor included as a GUI config option, is the fact that this feature is an ABB internal feature used for testing, thus a feature extending beyond just the ability to read state changes/updates of the virtual device. The ABB compliant way of being able to send commands/update state would thus be using flow/rules to identify the command sent (idp0000) and autoupdate/send back state to F@H (odp0000), similar to suggestion by @jannodeluxe.
Thanks - for of all, great we have a working option now with DeviceEmulation.
If we want to avoid that, could the binding do the magic or ship a openhab rule or node red flow that does ? I could not get the workaround proposed before to work and assume most might end up in that situation.
o
Hello Stian,
I have a problem with the freeathome binding. The connection to the access point is up and running. The scan also finds all devices except one. This is a 1/1-fold sensor / dimming actuator. I can create it manually with the ABB … number, but it still doesn’t work. Do you have any idea?
Try enabling “dummy things” and run scan once again to identify the device, and to see a full description of the device as shown in inbox. It could be the Device type ID is not autodiscovered/recognised by the binding.
