Time series documentation

[CatmanV2]

No error at all, it just returns the 'wrong' epoch time. Behaving differently between Reactor and MSR (I would assume by design)
<edit> It appears part of this might be caused but Reactor time() conversion returning epoch time in seconds. MSR time() is (or appears to be) returning epoch time in milli seconds.

The use case is as follow:
Set the alarm time (which varies, of course depending on weekends, holidays etc)
The alarm is triggered and turns on the Volumio player in the bedroom, gently increases the volume and wakes us up (ha!)

Subtract one hour from the alarm time, and that's when we want the heating to come on from its overnight low.

Of course I could set the alarm one hour earlier, use that to turn on the heating then wait an hour to trigger the Volumio, but that feels inelegant as well as prone to bad choices of alarm time.

If anyone has a suggestion of how the first case might be accomplished, it would be lovely.

Cheers

C

[Crille]

Do you need to set the heating in epoch time?
If so and Reactor for Vera is in seconds you could just convert from milliseconds with

substr(time(t), 0, 10)

and substract 1 hour by changing to this line instead

t.hour = hms[0] - 1,

in the above example.

[CatmanV2]

@crille Really appreciated

No I don't need to set the heating time, there's a rule that compares current time to the calculated time for heating on. Given that
time(0) returns epoch, that seemed a sensible way of doing it

Unfortunately truncating the epoch in ms simply knocks the milliseconds off so instead of getting Saturday, 1 January 2022 00:00:00.000 you get Saturday, 1 January 2022 00:00:00

It should be
Thursday, 21 July 2022 03:15:00
or
Thursday, 21 July 2022 03:15:00.000

Even using strftime returns Jan 1

Very very odd. Really appreciate your continued efforts though!

C

[Crille]

I'm a little lost and don't know what you actually want to achieve and what arguments you are giving time().
We might get different results as time() operates in the timezone set for the runtime.
I'll leave you with my tests and take a fresh look in the morning as it's getting late here. (sorry for Swedish in the screenshot as strftime() is locale-aware.)

[CatmanV2]

Ahh this appears to work, thanks so much!

I need to do some more testing, specifically around the testing of AlarmTimeSub1 vs current time but I very much appreciate your patience guiding this muppet!

<edit> So yes AlarmTimeSub1 evaluates perfectly. Now I need to compare that to actual time (if the actual time is later than AlarmTimeSub1, then I want the evaluation to be 'true')
time() >= AlarmSubTime1

Returns false.

C

[CatmanV2]

OK fixed it. Thanks, too early to be trying this stuff

strftime("%T", time()) >= AlarmSubTime1

Evaluates as true so that's great

C

[toggledbits]

FYI, @Crille has provided a correct example for computing an offset time to get an epoch (numeric) time to use for comparisons. The string comparison performed by strftime("%T", time()) >= AlarmSubTime1 is really poor programming style and should not be used; numeric comparisons are better here. Unfortunately, the responses don't give adequate detail as to what "wrong" answer is produced by @Crille 's solution, so I can't comment other than the critique.

[CatmanV2]

Thanks. I have no programming style so happy to be educated

<types long reply to explain the 'issue'>
<while typing resolves the issue>
<deletes explanation>

is time() >= HeatTime better style?

<edit>
I guess I'm still curious as to why
time([AlarmTime]) in MSR and time(AlarmTime) in reactor return a different stamp (apart from the ms vs s part that is)

Thanks again for all you do

C

[toggledbits]

@catmanv2 said in Variables for fun and profit:

is time() >= HeatTime better style?

Yes.

I guess I'm still curious as to why
time([AlarmTime]) in MSR and time(AlarmTime) in reactor return a different stamp (apart from the ms vs s part that is)

You haven't given any examples of this. I don't believe it to be true (except, as noted, for millisecond precision in Multi-Hub Reactor). My guess is you are not actually asking about the return values, but about why the functions take different arguments. The reason is that the expression language in Multi-Hub Reactor is entirely new, and while there is some overlap between them, I would argue that the newer form is vastly superior and corrects many errors (read: decisions I made that I later regretted) in the Lua-based form. Another reason is that Multi-Hub Reactor is not Lua-based, so I did not feel the need to be Lua-compatible, whereas Reactor for Vera, being a Lua plugin for a Lua system, is meant to capitalize on existing user experience with Lua on that now-defunct (Vera) platform.

Also, if AlarmTime contains the string 12:34:56, the using time([AlarmTime]) in either Multi-Hub or Vera Reactor would be passing incorrect arguments to the function. If you want to pass a string, you do so without [] surrounding. If you include the [], you are creating an array containing a string, which is nonsensical (to the function -- it sees an error). The documentation (for Multi-Hub) states that the function takes an optional single string argument, or up to six optional numeric arguments (representing in order given (year, month, day, hour, minute, second), or an optional dateparts-form object. The [] you see in the documentation is from an old-but-still-widely-used BNF form to indicate an optional argument, it is not meant to be literally included in your expression. So the following would be valid calls to time:

1. time() with no arguments (because all arguments are optional)
2. time( "2022-07-22T08:53:23+02:00" ) -- an ISO 8601 date string with TZ
3. time( 2022, 7, 22 ) -- produces midnight on 2022-Jul-22 in the host time zone (three optional arguments not given -- hour, minute, second)
4. time( 2022, 7, 22, 8, 10, 0 ) -- produces 8:10am on 22-Jul-2022 in the host time zone
5. and the dateparts() form has already been given in examples above by @Crille

Note that the string passed must be in ISO 8601 form, so a simple "12:34:56" time alone would not be parsable and produce an invalid result.

[CatmanV2]

@toggledbits OK I'll try to give an example (I'm sure / hopeful you can explain)

In my Reactor (and I'm pretty sure you set this up for me a couple of years back!) I have:
getstate( 46, "urn:upnp-org:serviceId:VClock1", "AlarmTime" )
Underneath is stated: Last result: "06:00:00"

Then we have
time(AlarmTime) - 3600
Underneath: Last result: 1658462400

In MSR we have:
getEntity( "vera>Alarm Clock" ).attributes.x_vera_svc_upnp_org_VClock1.AlarmTime
Underneath: Last value: (string) "06:00:00"

If we then do
time(AlarmTime) - 3600000 the result printed is
Last value: (null) null

time([AlarmTime]) - 3600000
Returns: Last value: (number) 1640995200000

Please note I changed the HeatTime in reactor to HeatTimeMSR in MSR just to demonstrate the 'difference' in output.

Clearly I'm missing something fundamental and obvious!

Cheers

C

[toggledbits]

@catmanv2 said in Variables for fun and profit:

If we then do
time(AlarmTime) - 3600000 the result printed is
Last value: (null) null

This is expected because AlarmTime contains only 06:00:00, which is not an ISO 8601-compatible string.

time([AlarmTime]) - 3600000
Returns: Last value: (number) 1640995200000

Also expected, as I said above, because the [] surrounding AlarmTime convert it to an array, which is a form of object, so time() is thinking its a dateparts()-compatible object and using what's available from it (which in fact is nothing at all, i.e. the "it's nonsensical" reference in that comment) to compute the time.

[CatmanV2]

So fundamentally Reactor's time and MSR's time are just different and behave differently?

<edit>
Or getstate and getEntity are returning something different from each other, I guess.

Thanks for the clarity there, and the patience

C

[toggledbits]

Many of the functions behave differently, and this is intentional. The functions of Multi-Hub Reactor are (in my view) an improved evolution of any same-named functions in Reactor for Vera. Reading the documentation is key to success.

I'm working right now (back at my desk, yay!) at expanding the parsing capabilities of time() to make your particular use case a bit easier.

[CatmanV2]

@toggledbits that's super. Thanks again for all your help!

C