@jimtng is more of an expert on this than I am but it’s always been my understanding that you cannot suppress a command or an update using the transformation profile. Something must be returned and if you return null the untransformed input is what passes through the transformation.
To “suppress” an update or a command in this way you must return the current state of the Item, or NULL or UNDEF (the latter two can only be used for updates, not commands). That prevents a change but you’ll still get the command/update.
In this case, returning null should discard the command and not propagated to the channel / handler / binding. So the binding will never see the command.
Then I set the switch to “On” in the GUI. And the switch in the GUI becomes true and stays true. I thought with Auto-Update set to false, the item in the GUI should remain false, but I’m not sure if I have understood that correctly.
The log shows that the command was received, and it appears to have been discarded, the hardware behind the channel remains definitely off.
When I toggle the switch back to off in the GUI, nothing happens. I would expect to receive a ‘CarChargerOn’ command OFF.
but nothing happens. Maybe because we have an asynchronous state between item and GUi?
Then I changed the code to:
(function(data) {
return;
})(input);
and
(function(data) {
return data;
})(input);
The behavior remains the same, the command is still not passed to the item, this concerns the ON and OFF command. Now I’m confused.
And here’s some background on what I’m trying to accomplish:
The Item controls a Shelly relay. The Shelly controls the charger of an electric vehicle, I want to block all “off” commands from GUI and other scripts when the current is >=8A.
I think one approach could be to solve this with transformation scripts, another approach could be to use a proxy item.
So when the shelly relay is OFF, and you send an ON command to it, the Shelly didn’t physically turn on? If you haven’t tried it, can you please try it? Feel free to use your original script as you posted in the original post above. I believe it should work.
There is another problem: the state update coming from the binding to the item is being discarded because you haven’t specified a script for it.
But one question, would should I do with:
“Item To Thing Transformation (DEPRECATED)” leave it empty or “|input” ?
First, I want to create a configuration that just passes everything through?
Is this the right configuration?
(function(data) {
const carChargerState = items.getItem("CarChargerOn").state;
console.error(`CarCharger TransformCmdInfo: ${data} CarChargerOnState: ${carChargerState}`);
console.error(`CarCharger C1: ${data === "OFF"} C2: ${carChargerState === "ON"}`);
if (data === "OFF" && carChargerState === "ON") { //Later on we will monitor the current, if it is above 9A, we will denie switch off
console.error("CarCharger TransformInfo - discarded");
return null;
} else {
console.error("CarCharger TransformInfo - passed");
return data;
}
})(input);
I started with a switch off device.
Then I set the switch to “On” in the GUI. And the switch in the GUI becomes true and stays true. Everything works as expected. The transformation script has been called, and has passed the command.
Then I set the switch to “Off” in the GUI, the switch in the GUI becomes false.
The TransformationScripts discards the command, and the Item stays “ON”.
The problem is, that the switch in the GUI becomes false, so we have an asynchronous state between the GUI and the Item.
An further “switch On” from the gui doesn’t invoke an “ON command”, the logs remain empty.
I think the transformation script works fine, but the problem is the gui.
You can do either, because if you specified “command from item”, the “item to thing (deprecated)” will be ignored. So you might as well leave it empty.
yes
I would probably leave “Item state to Thing” empty so it gets discarded. It shouldn’t normally be used. It shouldn’t affect you in this instance though, unless you manually update the item’s state, in which case you must leave it empty.
And also leave the deprecated one empty as explained above.
For clarity, I would probably rename data to command. Your code will read better that way.
This is when you really need to set the item to autoupdate="false".
BTW When you say Item I’m interpreting that as the “openHAB Item”, but I suspect you meant the “Physical device”.
This is where I can’t help much since I don’t use the UI that much. @rlkoshak ?
What happens when you send the ON command from say Karaf console, or from a script? E.g. you can create a Script in the UI (e.g. using RulesDSL)
CarChargerOn.sendCommand("ON")
Then try running that script. Does that send an ON command?
In this case though the device is still ON right? Because your OFF command earlier was discarded?
Then I set the switch to “On” in the GUI. And the switch in the GUI becomes true and stays true. Everything works as expected. The transformation script has been called, and has passed the command.
Then I set the switch to “Off” in the GUI, the switch in the GUI becomes false.
The TransformationScripts discards the command, and the Item stays “ON”.
I’ve tested this, with this short script:
@florian-h05 do you know why it behaves like this? I would think that at the very least, when refreshing, UI should show the actual state of the item (which is ON)
The problem here is a conceptual one: when flipping the switch or using any other control, the client (app or web page) sends a command to the respective item. There is no way for the client to know about the result of that command (whether it was applied successfully, was discarded or got lost in the binding due to some failure). This is why the clients can not update the switch in the latter two cases.
Fixing this would require sending events about the command result (including result and current item state) to the clients. Certainly possible to do, but quite a bit of work.
NB: since I have an RF actor that somethings is flaky die to poor signal, id appreciate such a mechanism too
AFAIK, in BasicUI, it would send the command, but its state remains unchanged. Its state changes depend on the SSE / state updates from the server. - EDIT this was incorrect
Click UI to turn it off → UI State: OFF, Item State: ON (not auto updated)
So to make UI state ON:
Item.postUpdate(OFF), Item.postUpdate(ON) → UI updates its state to ON
Make sure the item channel link is vetoing the “stateFromItem” by leaving it blank or always returning null so this doesn’t get propagated to the thing handler.
The UI should show the state received from SSE, just checked the code. I am currently on the way home from FrOSCon (where openHAB had a booth), so can‘t have a closer look, but I cannot see an issue with the code right away. TBH I haven‘t seen this behaviour before.
