I am using openHAB 4.0.3 as openHABian in a RasPi 4.
Using the HTTP binding for a connection with a Rademacher HomePilot, I found something strange about the “switch” type. Generally, there are various relay actuators in the Rademacher range, and their API access is “the usual stuff”: One current-status variable, one command for on, one for off. So far, so simple.
These switches have different sources to be operated from - automatization, manual interaction, etc. One way, among others, should of course be via the OH GUI and the OH rules. Therefore, it would be extremely useful if OH does not only issue commands and internally stores the last one, but also actively reads the current “real” status of the switch - something I would have expected as “so normal” to be of course existing already, but I found it to be different - at least from my observations.
It seems like the status of the switch is only read after a command was issued, but not on the configured regular timebase of the binding.
The status of the switch in the API is “0” for off and “100” for on, by the way. So a transformation is needed.
I tested this with three different configurations.
- Just read the status as a standalone string variable.
- id: Schalter_NL_Flur_2_Status
channelTypeUID: http:string
label: Schalter Nachtlicht Flur 2 Status
description: null
configuration:
mode: READWRITE
escapedUrl: false
stateExtension: /v4/devices
stateTransformation: JSONPATH:$.devices[?(@.did==<myDID>)].statusesMap.Position∩JS:SwitchToStr.js
with SwitchToStr.js transformation looking as such:
(function(x){
try{
if (x == 0) {
return ("OFF");
}
return ("ON");
} catch(e) {
return null;
}
})(input)
Result: works like a charm, it updates with the parametrized sampling rate and displays “ON” or “OFF” according to the real state. No matter from which source the relay is actuated.
- Proof-check: what happens if I apply it as the current state of the actual switch type with the commands already configured, but the state yet without a transformation:
- id: Schalter_NL_Flur_2
channelTypeUID: http:switch
label: Schalter Nachtlicht Flur 2
description: null
configuration:
onValue: '{"name":"TURN_ON_CMD"}'
mode: READWRITE
stateExtension: /v4/devices
offValue: '{"name":"TURN_OFF_CMD"}'
escapedUrl: false
stateTransformation: JSONPATH:$.devices[?(@.did==<myDID>)].statusesMap.Position
commandExtension: /devices/<myDID>
Result: The commands work like a charm, I can use the OH GUI to turn the switch on and off. The status of the switch is displayed “as previously commanded” for some seconds, then it changes to UNDEF. Well, all as expected.
- Do the real thing. Same as (2), but with status transformation. Note that the stateTransformation and stateExtension are identical to (1) except the JS filename.
- id: Schalter_NL_Flur_2
channelTypeUID: http:switch
label: Schalter Nachtlicht Flur 2
description: null
configuration:
onValue: '{"name":"TURN_ON_CMD"}'
mode: READWRITE
stateExtension: /v4/devices
offValue: '{"name":"TURN_OFF_CMD"}'
escapedUrl: false
stateTransformation: JSONPATH:$.devices[?(@.did==<myDID>)].statusesMap.Position∩JS:toSwitch.js
commandExtension: /devices/<myDID>
with toSwitch.js looking as such (note that this is identical to SwitchToStr.js except the return values):
(function(x){
try{
if (x == 0) {
return (OnOffType.from(false));
}
return ((OnOffType.from(true)));
} catch(e) {
return null;
}
})(input)
Result: Command / Control working perfectly as before in (2). Status is displayed “as previously commanded” and stays like this. Woo-hoo, works, even the transformation, I thought. 
Until I commanded the switch from outside OH and changed its state.
I ran two channels in parallel, just to be sure, the “only-string-status” as described in (1) and the configuration as a switch type in (3).
The string channel reacted as expected and updated its state. The log showed the INFO for the value change.
The switch channel never changed. No errors, no warning, nothing in the log. And exactly that’s what I don’t understand and would be grateful for help. 
(yes, I tried several times even with different switches. I waited several multiples of the update rate. I rebooted several times. It stayed all as described…)
