Hi all,
some more configs I found.
This is the definition for a closing contact switch:
Type contact : Schaltkontakt "Schaltkontakt" [
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.contact_state",
closedValue="closed",
openValue="open"
]
In addition, I improved the Env Sensor a bit:
// -----------------------------------------------
Type contact : UWS_Balkon_Regen "Umweltsensor Balkon Regensensor"[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.rain_detected",
closedValue="true",
openValue="false"
]
// -----------------------------------------------
Type contact : UWS_Balkon_Sonne "Umweltsensor Balkon Sonnensensor"[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.sun_detected",
closedValue="true",
openValue="false"
]
// -----------------------------------------------
This transforms the string value for the rain sensor with a closing contact type, making it look nicer in OH 
and I added the sun detected value as well. This, afaik, triggers when the first sun config value of the sun detection in the sensor trips.
This, no big magic, is the definition of a standalone sun sensor (the suction cup type window sensor):
Type contact : Sonnensensor_Arbeitszimmer "Sonnensensor Arbeitszimmer"[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.sun_detected",
closedValue="true",
openValue="false"
]
More or less the same for a motion sensor:
Type contact : Bewegung_Flur "Bewegungsstatus Flur"[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.movement_detected",
closedValue="true",
openValue="false"
]
An add-on for - in my case - the motion sensor: timestamping!
Type number : Bewegung_Flur_Zeitstempel "Bewegungsstatus Flur Zeitstempel"[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].timestamp∩JS:RademacherTsToUnix.js"
]
and with RademacherToUnix.js as such:
(function(x){
try{
return (parseInt(x) * 1000);
} catch(e) {
console.error('RademacherTsToUnix.js encountered an error: ' + e);
return null;
}
})(input)
as you can see, it’s a UTC timestamp with a resolution of 1 second (not too much, but okay for some compensation routines). I did not (yet) make it a timestamp type but just a number. But this works in a script, you can directly relate it to the values given by Date.now() 
Yet another new device: the door / window sensor which supports open, closed and tilted:
Type number : Fensterkontakt "Fensterkontakt "[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].readings.contact_state∩JS:DoorWindowToNumber.js"
]
Type number : Fensterkontakt_Batt "Fensterkontakt Batteriestatus"[
stateExtension="/v4/devices?devtype=Sensor",
stateTransformation="JSONPATH:$.meters[?(@.did==<myDID>)].batteryStatus"
]
with DoorWindowToNumber.js as such:
(function(x){
try{
if(x == "closed") {
return (0);
}
if(x == "tilted") {
return (1);
}
if(x == "open") {
return (2);
}
return null;
} catch(e) {
console.error('DoorWindowToNumber.js encountered an error: ' + e);
return null;
}
})(input)
The DoorWindowToNumber transform makes it a number, as the name says, which for me is nicer to handle and visualize in OH. But it’s no must, you can leave away the transformation and work with the strings as well.
And it has a battery state between 0 and 100 directly compatible to the battery state visualization of OH.
Last but not least, one thing I tried out and actually found working nicely - Auto / Manu Mode as a switch (read & write). This works for any Rademacher device with Auto / Manu mode the same, just set the DID and that’s it!
Type switch : Heizung_Arbeitszimmer_Auto "Heizung Arbeitszimmer Automatikbetrieb" [
stateExtension="/v4/devices",
stateTransformation="JSONPATH:$.devices[?(@.did==<myDID>)].statusesMap.Manuellbetrieb",
commandTransformation="JS:AutoManuMode.js",
commandExtension="/devices/<myDID>",
onValue="0",
offValue="100"
]
and with AutoManuMode.js as such:
(function(x){
try {
if (x == "0") {
return ("{\"name\":\"AUTO_MODE_CFG\", \"value\":\"true\"}");
}
return ("{\"name\":\"AUTO_MODE_CFG\", \"value\":\"false\"}");
} catch(e) {
console.error('ManuAutoMode.js encountered an error: ' + e);
return null;
}
})(input)
Note that the reading of the mode in /v4/devices is Manu Mode which reads “0” for automatic and “100” for manual mode, while the setter command is complementary: Auto Mode and with “true” for automatic and “false” for manual mode. This works, and I verified that both of the values always change together and immediately.
Please also note that I added some really good news to this older post - it’s possible to extract HomePilot’s API secrets by WireShark, and I added scripts to trigger scenes as well as automations (“Auslöser”) by their clear names!
UPDATE: It’s been a while, but more good news!
The API of Rademacher seems to have no callback possibility at all. At least I found no hints to this, and their own config website uses regular polling to update its values. But the HomePilot is compatible to Philips Hue and can integrate a Hue bridge.
This, and this cannot be overestimated, offers the possibility of the HomePilot proactively outputting trigger events in real time!! 
instead of polling it to death with the HTTP binding for close-to-realtime applications.
How to do this?
- Enable the Hue Emulator in OpenHAB and register as a Hue bridge in HomePilot (non-trivial, see below!)
- Create a proxy item of type Switch, assign category “light”, add Non-semantic tag “Lighting”. You will see a dimmer light with the name of the proxy item in the Homepilot devices then. (HomePilot does not support the Zigbee switch type, so use a light).
- In HomePilot, include this light in scenes and triggers of your choice, command it to be “On” and “Off”.
- You will see the proxy item react to these commands almost instantaneously! This, you can use in all OpenHAB ways from there on
Nevertheless, HomePilot will not communicate with the Hue Emulator right away. The reasons are tricky, took me some days. The solution is simple, anyway, and can be found here.
Have fun!
) need some adjustments. Instead of “GOTO_POS_CMD” (in RollerShutterPositionJSON.js) there need to be “TARGET_TEMPERATURE_CFG”, right?
No changes possible.