Epoch time converter?

[Moskus]

I have a CNC machine connected to HS via MQTT. It reports the job start time and job end time using Epoch time. Is there an easy way to convert this using mcsMQTT or should I just write a simple script?

[Michael McSharry]

I believe the expression function is something like UnixTime. Look in mcsMQTT.pdf in Table 1 or 2. I am away now. It would go in Edit tab expression text box with something like UnixTime($$PAYLOAD. I believe there are also Date Time functions where you could add the payload seconds to get local time.

[Moskus]

Wow, you really think of everything!

It might be me, but I can't get it to work. I have an epoch value with milliseconds, which might be too large. So why not divied it by 1000? That works fine!
($$PAYLOAD: /1000) gives 1645179546,98. Excellent!

The function is listed in Table 3 as :

Public Function Unix_time(ByVal n As Object) As String

This doesn't work:

• Unix_time($$PAYLOAD
• Unix_time($$PAYLOAD: /1000)
• Unix_time(Round($$PAYLOAD: /1000))
• Round($$PAYLOAD: /1000)
• Round($$PAYLOAD

They all return "Unknown".

EDIT: Nevermind, I found it. The number of cecimal places is listed as optional (as I see it), but it's not.
Public Function Round(ByVal value As Object, ByVal prec As Integer = 0) As Double

This worked fine!
Unix_time(Round($$PAYLOAD:/1000,0))


... but I would've thought that this worked too, but no..
Format_date(Unix_time(Round($$PAYLOAD:/1000,0)), "dd.MM.yy HH:mm:ss")

[Michael McSharry]

I looked into the Date/Time functions and made some changes.
I added the following two that should handle all operations. Format_DateTime uses the input as local date/time and does no localization time conversion. Local_DateTime assumes the input is GMT and converts it to local time. The fmt format is per .NET DateTime formatting.
Local_DateTime(d as object, fmt as string) as string
Format_DateTime(d as object, fmt as string) as string

If d is a valid date then the input is a date/time. If d is a number then the input is Unix time as number of seconds since 1970. Otherwise input is considered to be now. This obsoletes the Unix_time and Unix_date functions.

The parser does not have implicit type conversions. That is the reason for Round and SRound where the first is a number and the second is a string. Usually quotes can be added around a number to convert it to a string. For example "$$Value:" would be a string after the replacement for $$Value: is done.

Nesting of functions sometimes has difficulty. Explicit expressions can usually overcome this. Similar to using parenthesis in numeric expressions to force evaluation order. Something like the following are examples of specifying explicit evaluation order.
<<Format_date(Unix_time(Round($$PAYLOAD:/1000,0)), "dd.MM.yy HH:mm:ss")>> or even
<<Format_date(<<Unix_time(Round($$PAYLOAD:/1000,0))>>, "dd.MM.yy HH:mm:ss")>>

The above with 5.23.5.0 can be done more simply with the new functions.

The updates for 5.23.5.0 are at the bottom of the first post at https://forums.homeseer.com/forum/hs...ge-log-hs4-hs3

It was a good catch for the ROUND function use in this context. I would not have though of it without using the debugger.

The current mcsMQTT.pdf does have ROUND with the precision as required. I believe earlier versions did show it as optional. The internal function I copied has it optional, but when put in the context of the parser it became required.

[Moskus]

Most impressed!!
I need to fire up the CNC machine again very soon to see if this works. Apparently, the "Expression" is only applied when data is received (and that's OK).