Number:Time UoM formatting question

[AndrewFG (Andrew Fiddian-Green)]

So why was it showing day 0 yesterday (less than 24 hours elapsed) and day 2 today (27 hours elapsed)?

[rossko57]

Set your root value back to what it was, and find out. This just isn’t going to do what you want.

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

Set your root value back to what it was, and find out

Sorry but I don’t understand what you are suggesting here?

[rossko57]

Set your Item value to 999 minutes, see what day value you get.

[AndrewFG (Andrew Fiddian-Green)]

You are right, it shows 1 day.

[rossko57]

I think a little transform for your display is going to be the best bet.
Knew I’d poked around this before -

Number:Time formatting for display

A Number:Time type Item shares the characteristic of other Quantity Types in that it’s state is represented by a single number + unit, as a pair. openHAB can freely work with a variety of units, and convert values like say “90 s” to “1.5 min”, but neither of these are particularly human-friendly - we tend to think in clock-like terms, more like “1 min 30 secs”. There is no standard feature to perform this kind of formatting. However, transformations are very versatile and meant for tasks like…

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

I think a little transform for your display is going to be the best bet.

Thanks @rossko57 you are right. However in the meantime I had written my own transform below.

Notes:

• The Item definition casts the Channel’s Number:Time value to a String (%s)
• The transformation script casts it back to a DateTime
• And the script also has to scale the value /1000 (I am not sure why…)

Item

String System_CPU_Uptime "System CPU Uptime [JS(uptime.js):%s]" <time> {channel="systeminfo:computer:g24:cpu#uptime"}

uptime.js

(function(dateTimeString) {
    var mins = Date.parse(dateTimeString)/1000;
    var days = Math.floor(mins / (24 * 60));
    mins = mins % (24 * 60);
    var hours = Math.floor(mins / 60);
    mins = mins % 60;
    return days + "d, " + hours + "h, " +  mins + "m";
})(input)    

[rossko57]

@AndrewFG

• The Item definition casts the Channel’s Number:Time value to a String (%s)
  …
• And the script also has to scale the value /1000 (I am not sure why…)

I think that’s why, you’re getting some default effect in milliseconds but it will be going all wrong because it ignores the supplied ‘mins’ unit without a real Quantity type involved…

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

I think that’s why, you’re getting some default effect in milliseconds but it will be going all wrong because it ignores the supplied ‘mins’ unit without a real Quantity type involved…

Err. Not really. It is even odder than that…

I did some debugging and I can see the following…

• The transform is called with a proper date argument string (e.g. “1970-01-01T01:03:18+01:00”) – which is indeed the actual uptime 3 hours 18 minutes (aka 198 minutes) since the machine was powered on.

• The val mins = Date.parse(dateTimeString)/1000 statement produces a value (e.g. 198) – which is identical to the actual uptime – in minutes!!

• The function returns a string (e.g. “0d, 3h, 18m”) which is also identical to the actual uptime.

So it seems that openHAB itself is behaving as it is supposed to, and that the error is actually in the JavaScript Date.parse() function; which actually returns a result in milli-minutes instead of milli-seconds – contrary to what is written in that function’s documentation.

=> So I wonder if openHAB is using a “funky” JavaScript interpreter of some sort?

PS in case it might be relevant, my system is running on Raspbian

[rossko57]

If your binding channel is really of number:time type I would be very suspicious of what happens when you link it to a String type Item. Clearly the channel should not be sending “1970-01-01T01:03:18+01:00” to the Item (what would be the meaning of +01:00 in a duration) and I suspect the framework is messing up when mis-matching types.
Not so much a bug as a misconfiguration.

It’s been seen before that a hopeless channel-Item mismatch can result in unexpected datetime looking results, with no time involved. I expect its just the last action in a list of possible intternal transforms.

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

It’s been seen before that a hopeless channel-Item mismatch can result in unexpected datetime looking results, with no time involved. I expect its just the last action in a list of possible internal transforms.

You are right.

@rossko57

the channel should not be sending “1970-01-01T01:03:18+01:00” to the Item

Indeed. That string is completely munged; the correct string is 1970-01-01T03:18:00. (I forgive Date.parse() for choking on such a munged string). But IMHO if the framework can’t deliver a valid DateTime string, it should certainly not send a munged string; it should ideally send something valid, but otherwise it should send nothing at all. (Perhaps I will fix the code and raise a PR accordingly…)

---

Below is my second attempt at an Item definition and matching JavaScript transform: this (also) produces the correct display – without the ‘benefit’ of having one bug coincidentally correct another.

Item

Number:Time System_CPU_Uptime "System CPU Uptime [JS(24g-uptime.js):%d]" <time> {channel="systeminfo:computer:g24:cpu#uptime"}

uptime.js

(function(mins) {
    var days = Math.floor(mins / (24 * 60));
    mins = mins % (24 * 60);
    var hours = Math.floor(mins / 60);
    mins = mins % 60;
    return days + "d, " + hours + "h, " +  mins + "m";
})(input)    

[rossko57]

@AndrewFG

but otherwise it should send nothing at all.

Need to take a bit of care - it could be perfectly viable to send from number:time type channel to a String type Item … with an appropriate transform profile. The channel should not block this.

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

it could be perfectly viable to send from number:time type channel to a String type Item

Agreed. But it MUST be a valid string.

[rossko57]

Let me put it another way … if you pipe your number:time channel output into a transform profile, what do you get? That’s the part that needs to work. Linking a number:time to a String Item without a profile is not valid, and indeterminate results might be expected.

[AndrewFG (Andrew Fiddian-Green)]

I’m sorry but I don’t understand your meaning. Can you please clarify?

[rossko57]

Well, linking a rollershutter type channel to a Player type Item isn’t going to give any sensible result. Or a datetime channel to a Color Item.
The framework doesn’t support currently linking mis-matched types (except via the intermediary of a profile, where it’s up to you to manage a sensible output).

You’ve got an expectation that linking a number, specifically a number:time subtype, channel directly to a String Item should give you a sensible result. I don’t think that’s in the specification at all, it’s just a type mis-match. Getting a datetimey looking thing in this case is just some artefact of breaking the rules.

It gets harder when considering commands; what’s a number:time channel going to do with valid String command “banana”, or a rollershutter channel with command PLAY?

However, we can’t just block such linkages in the framework. It’s perfectly correct to link a contact channel to a DateTime Item - using a timestamp profile.
You might get fancy with the UI and not offer silly linkages unless a profile is selected. People using xxx.items files will still be able to break it, though.

[AndrewFG (Andrew Fiddian-Green)]

^
@rossko57 I am still not sure that I understand your issue, but…

@rossko57

we can’t just block such linkages in the framework

… please rest assured that I am not planning to “block” anything. And even if I were to propose a PR then obviously it would be subject to the normal review process.

---

To reiterate, my issue is/was that the binding/framework was sending the string 1970-01-01T01:03:18+01:00 from its “upTime” Channel to a String Item, and my (and your) initial reaction was that that string is wrong. However on reflection it is actually completely correct…

• 1970-01-01T01:03:18+01:00 semantically equals 1970-01-01T00:03:18Z (in my time zone BST)

• The binding was reporting ‘uptime = 198 minutes’ = 3 hours 18 minutes

• The binding was not providing UoM so the framework was assuming ‘uptime = 198 seconds’ (i.e. the default UoM) = 3 minutes 18 seconds

• … which is exactly the same as 1970-01-01T00:03:18Z

Ergo: it is all actually working ‘as designed’…

[rossko57]

@AndrewFG

The binding was not providing UoM

So … it’s just a number channel, after all? (Which is what the docs suggest)

@AndrewFG

it is all actually working ‘as designed’

And you think a plain number type channel feeding into a String type Item should give a DateTime string.

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

And you think a plain number type channel feeding into a String type Item should give a DateTime string.

There’s no need to be snide. I’m not thinking anything of the sort. But it seems to be doing just that.

[rossko57]

Not meant to be snide. I think it’s a bizarre thing to do, transform a number to a datetime-ish string. But I don’t think it’s a bug nor working as designed, it’s an odd side effect of an invalid configuration.