How about a small math exam for your Vera?

Ap15e · March 28, 2011, 9:22pm

Please post the results for your Vera and the version (V1,V2):

luup.log('MYVERSION: '..luup.version_branch ..'.'..luup.version_major..'.'..luup.version_minor)
luup.log('CORRECT (1234567890)? '..tonumber(math.max(1234567890, 0)))
luup.log('CORRECT (seconds = 00)? '..os.date('%c',1301191800))

iflym3 · March 28, 2011, 9:28pm

I know that I am being stupid, but ah… where do I put this programming script at in Vera?

Ap15e · March 28, 2011, 9:31pm

MiOS developers → Test Luup code (Lua)

… then extract the result from /var/log/cmh/LuaUPnP.log

sparkejj · March 28, 2011, 9:53pm

luup_log:0: MYVERSION: 1.1.1186 <0x340e>
luup_log:0: CORRECT (1234567890)? 1234567936 <0x340e>
luup_log:0: CORRECT (seconds = 00)? Sat Mar 26 22:10:08 2011 <0x340e>

iflym3 · March 28, 2011, 10:07pm

luup_log:0: MYVERSION: 1.1.1234
luup_log:0: CORRECT (1234567890)? 1234567936
luup_log:0: CORRECT (seconds = 00)? Sat Mar 26 2

fall-line · March 28, 2011, 10:09pm

V2 (as you would suspect from the below)
luup_log:0: MYVERSION: 1.1.1234 <0x340e>
luup_log:0: CORRECT (1234567890)? 1234567936 <0x340e>
luup_log:0: CORRECT (seconds = 00)? Sat Mar 26 19:10:08 2011 <0x340e>

futzle · March 29, 2011, 11:10am

It’s OpenWrt’s fault. r18159 changed the Lua number representation to float, ostensibly to save memory. r23284 changed it back to double, given Lua’s unwillingness to turn numbers back into integers, it messes with epoch times.

Here is the email discussion: https://lists.openwrt.org/pipermail/openwrt-devel/2010-October/008193.html

Vera’s build of Backfire (r21639) is during the reign of float. The fix is for MCV to update the version of Backfire that it installs.

Ap15e · March 29, 2011, 4:43pm

A big “Thank you!” to all posters.

@futzle

Yes, I know. I’m desperately trying to convince MCV that something is seriously wrong with the Lua component of the current OpenWRT builds for Vera V2 - no acknowledgement so far …

futzle · March 29, 2011, 8:38pm

Yeah, I agree. The fact that the OpenWrt developers chose to switch it back too is a bit of a giveaway, isn’t it?

Of course, if MCV released the OpenWrt source code like they are legally required to do we could just compile our own…

iflym3 · March 29, 2011, 8:43pm

do I see a suggestion to a custom firmware? lol!

Ap15e · March 30, 2011, 7:30am

http://bugs.micasaverde.com/view.php?id=1451

mcvflorin · November 24, 2011, 6:39pm

Vera has finally passed the math exam!

[url=http://bugs.micasaverde.com/view.php?id=1451]http://bugs.micasaverde.com/view.php?id=1451[/url]

Ap15e · November 25, 2011, 6:13pm

Vera V3 or (Vera V2 and Vera V3)?

mcvflorin · December 1, 2011, 1:32pm

Only Vera 3 for now.

strangely · December 2, 2011, 4:24pm

If its only V3 for now then why has the mantis been closed?

Now that its closed, then my guess is that it will get forgotten and never fixed for the V1 and V2!

mcvflorin · December 5, 2011, 9:29am

CJ said that he will try to fix this for Vera 2, but didn’t have time last week.
You can reopen the ticket if you like.

mcvflorin · December 13, 2011, 4:19pm

Now fixed for Vera 2.

325xi · December 19, 2011, 8:01pm

Is this related to vera’s inability to get non-integer values from temperature and other sensors?

futzle · December 19, 2011, 8:35pm

Not related.

Ap15e · December 19, 2011, 10:21pm

Is this related to vera's inability to get non-integer values from temperature and other sensors?

On the surface Vera’s inability to provide non-integer values is caused by not adhering to the UPnP specification. The UPnP specification clearly states that temperature values are centi-degrees, not degrees. In consequence, all temperature related UPnP variables are off by a factor of 100 - and there is no way left to put non-integer values into the UPnP variables.

MCV shouldn’t use the [tt]upnp-org[/tt] namespace for non-compliant variables - now it’s too late. I cannot think of a fix that wouldn’t break existing Luup code that assumes that temperature values are integer degrees. In other words: don’t expect a fix soon …