my objective is to have a switch on a knx device that responds to the states defined by openhab, because there is no real knx device that replies the actual state. The state of the item is persisted in mapdb.
I created two things (one for the sending the action on the knx bus, one for sending the state to the bus) and linking them inside an item with the profile “follow”.
The on/off of the physical buttons works as expected but the log shows, that the corresponding item gets regularly “received command off”.
Because I use changes of the item state in a rule, that creats a mess.
What did I do wrong?
Type switch-control : virtual_KNX_Push_Video “Video” [ ga=“0/1/206”]
Type switch-control : virtual_KNX_Push_Video_State “Video State” [ ga=“0/1/207”]
I think perhaps, having two switch-control type channels.
Let’s look at how an ‘ordinary’ switch type channel is intended for an ordinary actor - a light bulb, say.
From openHAB, we can command an Item on or off from rule or UI. The binding passes commands onto KNX bus.It can report its state back to us.
If there are incoming KNX messages, they get turned into state updates for the openHAB Item.
switch-control type channels are not often used, and work in an unusual way for channels.
Messages from KNX become openHAB commands. That’s do-something instructions. switch-control is intended for something like a button panel; the user pokes a button and an instruction is issued and passed into openHAB.
And openHAB Item state is passed out to KNX - might be used with an status light or such.
openHAB autoupdate feature comes into play here. It’s enabled by default on each Item, and will act on Item commands to affect Item state usually. You can disable that if you want.
I don’t really understand what you mean here, “switch” is ambiguous, but I don’t think you need two channels, just one.
Do you want openHAB to look like an actor or look like a control panel, from KNX side?
If it’s about a wall switch which is used to switch on/off a (non knx) device, you will need two GA (one to send the command, one to receive the state) and one switch-control Channel.
Type switch-control : virtual_KNX_Push_Video "Video" [ ga="0/1/207+0/1/206" ]
This way, openHAB will receive commands via 0/1/206 and will send state updates via 0/1/207
It is essential to understand, that *-control Channels are the complete reverse of a normal channel.
I.e.: you have to use received command as a trigger in Rules. You have to use postUpdate() to send a status change to knx.
But ou are free to link a *.control channel to awn existing Item, which will receive commands from knx without any rule and will send its status to knx without any rule. You don’t need a profile either.
I tried that you wrote and added a rule with “received command” which should set the info light on the knx switch to on with virtual_KNX_Push_Video.postUpdate(ON)
It worked and I removed the rule. it still worked.
Now, it does not work with or without the rule which issues virtual_KNX_Push_Video.postUpdate(ON)
Type switch-control : virtual_KNX_Push_Video "Video" [ ga="0/1/206+0/1/207" ]
I push the button on my physical knx panel which is configured as a single button on/off device. This button has an info light which shows green for on and red for off
the panel sends the state using the knx bus to the GA, which is configured in openhab
openhab reads the command from the knx bus and replies with a new state for the info light on the panel. it also executes some rules.
*the knx panel reads the command and changes the state/info light of the button
I am using the openhab logviewer (frontail) to keep an eye on what happens.
The thing and the item are correctly linked, I checked and it worked by chance for some time.
autoupdate is not disabled (I would not know how to enable them and my “normal” knx buttons on the panels work perfectly)
Type switch-control : virtual_KNX_Push_Video “my description” [ ga=“0/1/208+0/1/209”]
2021-05-26 14:07:35.279 [INFO ] [openhab.event.ItemCommandEvent ] - Item ’ virtual_KNXTPusher_Video’ received command ON
2021-05-26 14:07:35.281 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ’ virtual_KNXTPusher_Video’ predicted to become ON
the knx bus:
no matter if I use [ ga=“0/1/208+0/1/209”] or [ ga=“0/1/209+0/1/208”], openhab sends on 0/1/208
if I use [ ga=“0/1/209”], openhab sends nothing
When I only use “received command” as the event, rules do not react to a change from another switch-control. I have to use “received update” so that the rule reacts.
But even then, the rules does not always fire. Now, only the state is updated but the rules which should react to “receivesd update” AND “received ommand” does not execute.
No, never! If you did configuration via text files, please ensure that the new configuration was loaded properly (i.e. take a look at the UI and be sure that GA have changed)
openHAB will NEVER send on a secondary GA but only on the first GA given to a parameter.
No, switch-control will receive a GA from knx and will send it as a command to the openHAB bus (which will result in a received command to the linked Item).
A changed status of the Item will result in a message to the knx bus (from the first configured GA)
On the other hand, switch will receive a GA and will send it as a status update to the openHAB bus (which will result in a status update to the linked Item).
Reminder that small Thing edits, particularly when using xxx.things files, are not always immediately implemented by some bindings.
When you’ve edited everything as you want, do a binding bundle restart tobe sure the new settings are “picked up”.
I used only the following code. It worked only after restarting openhab 3.0 accidently by using the “install openhab 3.0” option in openhabian-config, normal restarts and bundle restarts did not change a thing.
seems to be the solution. It now works again but who knows how long. Last time, updating the xxx.items file broke everything again.
It ssems openhab 3.0 is less responsive (like molasses) to changes than 2.5. Additionally, changing the files seems to be treated by openhab with a “perhaps I follow your files, but maybe I pretend I do but really ignore that”…