Busch-Jaeger Free@Home

Add-ons Bindings
,
539

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.

540

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.

  1. I have to change “ID of Data Point” from “idp0000” to “odp0000” and “ID of update Switch State” from “odp0000” to “idp0000” to get anything to work
    2a. I can then switch in OpenHAB and the virtual switch in FreeatHome follows on and Off
    2b But if I hit the virtual Switch in Freeathome, nothing happens - the switch in OpenHAB does not trigger (and the state in Freeathome does not change).

Any insights? Thanks.
Olaf

541

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

542

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

543

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

544

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”:""}]

545

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.

546

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 ?

547

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

548

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.

549

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

550

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?

551

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.

552

Thanks, I tried and with the missed device it was detected but no channels. What do I do now?

553

Yes, it was just to get the device displayed in the inbox. Next, could you screenshot the device as it is displayed in the inbox? Would need the Device type ID (4 digit number) as included in the device name for further investigation. The sensor/dim actuator is not included in the binding as per now, so further investigation wrt channel/idp/odp would be required.

554

Okay.
Here is my screenshot
Bildschirmfoto 2021-07-31 um 19.35.59

555

Right, so the 1017 device is not included by the binding as per now. We would need to identify channel and idps/odp for the device to get it included.

556

Hello. Sorry for my late answer.
How do I identify the channel and idps/odps?

557

Would need to sniff the response of the device, either via web browser (network inspector) or via ABB Developer program (Postman for Cloud API or Swagger for REST API depending on which SysAp version you have).

558

@Olafsc @jannodeluxe
I have been playing around with the binding in an attempt to have the binding automatically handle virtual switches, i.e. without using virtualDeviceEmulation, and to have the binding read/write values without having to use rules.

I.e. my attempt has been to update/read idp value on both side of things, and to automatically send an update to odp to also synchronise/update the SysAp. Meaning, when triggering virtual switch from OH side using idp, the binding should also send the value to odp to update everything on the SysAp side. Also, when triggering the virtual switch from the SysAp side, the binding is set up to read the idp value, and should reply automatically to the odp to keep everything synchronised.

Please feel free to test. Haven’t tested myself yet, as I will have to remove reference to virtualDeviceEmulation first. Would also need to delete and recreate thing for proper discovery/Thing initialisation.
org.openhab.binding.freeathome-3.2.0-SNAPSHOT.jar

NOTE:
I have started testing myself, and realised there had to be made some modifications to the binding to achieve the automatic odp update. Link above is updated, and the binding now seems to handle the virtual switch correctly, without using virtualDeviceEmulation, and I also did not have to delete/recreate thing.

1 Like