The loggers defined in the config file inherit from higher up loggers. So org.openhab
is defined as a logger with level INFO meaning that anything under org.openhab
, like org.openhab.model.script.meteoalarm-wind
will already be configured to log out to openhab.log at the INFO level. So the line you added isn’t really necessary. Though it certainly shouldn’t be a problem either.
Well, like I said at least twice in my original reply, and will repeat here again, I’ve never heard of someone logging from a transform and I will not be surprised if you cannot log from a JS transformation. Assuming you do everything correctly as one would do in a JavaScript rule, which appears to be the case, and you still don’t get any logs that strongly implies you cannot log from a JS transform.
OK, that’s good news. It means one can log from a JS transformation.
This is good to know as it means that perhaps more stuff is also possible from a JS transformation. For example, perhaps the ItemRegistry can be pulled down and the state of some other Item can be used to transform the state. That is a much asked for request.
As for the null thing, as rossko57 indicates, null
isn’t an array. There is no such thing as null[1]
. You have to test for null
first.
Note, It’s also possible that the chained transformations do not work the way you think. I don’t use the HTTP binding but I believe it works the same as the MQTT binding. In the MQTT binding, if the REGEX doesn’t match anything the transformation just stops. It doesn’t return null
to the next transformation in the chain. The event is essentially just thrown away. That is by design as the REGEX part is used as a filter so the next transformation in the chain only processes relevant messages.
Assuming that the HTTP binding works the same, you’ll have to abandon the REGEX transform and do it all in the JS transform, or you’ll have to abandon setting the Item to 0 when the REGEX fails to match anything.