Transformation of overtemperature value 0 and 1 defect

Tags: #<Tag:0x00007fc90dd61bf8> #<Tag:0x00007fc90dd61ab8> #<Tag:0x00007fc90dd61860>


I’m struggling with the transformation of overtemperature values of my shellys. It looks like that the returned value from the shelly is correct, but the transformation is defect. I’ve tried it in two different ways (map and js); both approaches results to the same problem. The required transformation addons are installed and active.


Type number : overtemperature "Temperatur-Status" [ stateTopic="shellies/shelly1pm-<id>/overtemperature" ]

Number entrance_light_outdoor_north_info_overtemperature "Temperatur-Status [%.0f]" <temperature> { channel="mqtt:topic:shelly_entrance_light_outdoor_north:overtemperature" }
String entrance_light_outdoor_north_info_overtemperature_trans "Temperatur-Status [JS(shelly.overheating.js):%s]" <temperature> { channel="mqtt:topic:shelly_entrance_light_outdoor_north:overtemperature" }


(function(i) {

    var result = "Undefiniert: " + i; // DE
    if (!isNaN(i)) {
        if (0 == i) {
            result = "Normal"; // DE
        } else {
            if (1 == i) {
                result = "Überhitzt"; // DE

    return result;
}) (input)

The web UI displays then: “Undefiniert: 1970-01-01T00:00:00.000+0000”

Prior to the JS approach, I’ve tested it with a map file (, which contains the following entries:


The web UI displays then the default value “Undefiniert”. The logfile has a corresponding entry:
Could not transform '1970-01-01T00:00:00.000+0000' with the file '' : Target value not found in map for '1970-01-01T00:00:00.000+0000'

Even if I add “1970-01-01T00:00:00.000+0000” as entry to the map file, the transformation fails with the same entry in the logfile.

The value of the non-transformed item (based on the same channel!) returns the correct 0. Therefore it looks like, that OH3 does auto-convert a value “0” to a timestamp “1970-01-01T00:00:00.000+0000”.

Have I make a mistake?

Bug in OH3?

Any ideas?


Values are always passed into (and out of) transformation in string form.
You’ll need to parse your input to find out if it is NaN in the javascript.

I would have expected the MAP to work.

I think the problem might be that you are trying to pass a Number to a String Item. String items accept 3 different data types: UnDefType, StringType and DateTimeType. My guess is that it tries to convert the number to the most fitting type, which is DateTime since that is also just a number (and the value 0 is 1st Jan 1970 at 00:00).

Either use a Number Item (the transformation in the state description works just the same) or move the transformation to a profile so it’s transformed before the Item gets the state.

When used in the Item label like this, the transformation output is never passed to the Item state, only to the UI. It’s purely for display.

You can certainly get weirdness mis-matching channel and Item types
Shelly binding docs don’t mention an overtemperature state channel, is this a new thing? Wouldn’t it be a binary/switch?

Thank you!

You (both) are right! I took a string item, because I thought, that the transformation is done on item level and not only for the label. But now, with using a number item, it works!

The overtemperature is one of the shelly topics, but surprisingly it is not a common topic, i.e. not documented on the common level. It is part of the topic docs of a specific shelly model, e.g. 1PM - probably, this topic is not available for every model.

Ah right, OH Shelley binding docs do give a list of unique channels per model. Maybe this one needs adding to docs (and maybe other devices).