I have had two power outages here in the UK recently - rural area, overhead supply! All fhem control has come back up except that both times the Cube (eq-3 version) seems to have reverted to CET, ignoring the timezone previously set by Max!_Setup and night setback and other changes are an hour out.
Both times I have resorted to Max!_Setup on an XP install I have and both times the timezone setting has been blank. It is not blank if checking a running sytem that has previously had timezone set. I have no idea whether the Cube retains timezone setting over power off - perhaps no is the obvious answer and this is expected behaviour! I guess that most Cube users are using CET so have no problems in this respect.
Setting the clock from fhem with
set ml clock
once Europe/London has been set by Max!_Setup, is fine, time difference 0, so the Cube is using the tz setting - I think?
I'm aware of http://forum.fhem.de/index.php/topic,11976.msg71034.html#msg71034 (http://forum.fhem.de/index.php/topic,11976.msg71034.html#msg71034) and will try that when I next have an outage but I'd then have to alter every new revision of 00_MAXLAN.pm I think. I'm also aware that Cube settings/communications are still not fully understood - as a mere user I am very grateful for what has been done so far.
Any thoughts?
Would allowing a time offset when setting the clock from fhem be possible or introduce additional complications?
It would certainly be possible. I guess a "attr" on the MAX_CUBE component would suffice. Unfortunatelly I currently don't have any time, but if you provide a patch, I can check it in.
Thanks for the reply. Not sure I'm confident enough to produce a patch (without breaking something else).
I'm not sure the http://forum.fhem.de/index.php/topic,11976.msg71034.html#msg71034 (http://forum.fhem.de/index.php/topic,11976.msg71034.html#msg71034) method is the right solution here. I have been running with it since shortly after my first post but I still see messages such as
2014.02.12 18:14:13 2: MAXLAN_Parse: Time difference is 60 minutes
2014.02.12 18:14:13 2: MAXLAN_Parse: Cube thinks it is 12.2.2014 19:14
and
cubeTimeDifference 60
Edit: however everything is working to expected times here.
I have just checked everything again this morning after realising I have been looking at the wrong device, that last statement is wrong, timings are an hour out.
A bit of playing with Max!_Setup and Wireshark and I have another timezone string for London/BST of R01UAAAKAAMAAAAAQlNUAAADAAIAAA4Q
I have modified 00_MAXLAN.pm and will see how things go from here
ZitatIt would certainly be possible. I guess a "attr" on the MAX_CUBE component would suffice. Unfortunatelly I currently don't have any time, but if you provide a patch, I can check it in.
I have been running a modified 00_MAXLAN.pm for several weeks now with no issues.
I have added an attribute for setting alternative timezones, the default CET-CEST is retained. Options are GMT-BST, CET-CEST, EET-EEST, FET-FEST, MSK-MSD and the following with no DST settings, GMT, CET, EET. (FET-FEST and MSK-MSD regions do not use DST).
All new timezones have been tested for at least 24 hours, GMT-BST has been in use here for some three weeks.
All timezone strings are identical to those used by the official MAX software. The decoded strings differ only in timezone name and winter/summer time offsets.
I have attached a patch file, hope it's in a useful format.
Thanks for your contribution. Your findings are impressive.
I'm not quite sure that I understand your patch, though.
You define %tz_list, but never use it. You also check AttrVal($hash->{NAME},"timezone",""),
but never use its value.
Are you sure that you submitted the complete code? The patch you submitted follows:
--- home/00_MAXLAN.pm 2013-12-31 03:11:18.000000000 +0000
+++ home/00_MAXLAN.pm 2014-03-04 09:10:45.300955469 +0000
@@ -51,7 +51,8 @@
$hash->{DefFn} = "MAXLAN_Define";
$hash->{UndefFn} = "MAXLAN_Undef";
$hash->{AttrList}= "do_not_notify:1,0 dummy:1,0 set-clock-on-init:1,0 " .
- "loglevel:0,1,2,3,4,5,6 addvaltrigger ";
+ "loglevel:0,1,2,3,4,5,6 addvaltrigger " .
+ "timezone:CET-CEST,GMT-BST,EET-EEST,FET-FEST,MSK-MSD,GMT,CET,EET";
}
#####################################
@@ -215,9 +216,38 @@
#This encodes the winter/summer timezones, its meaning is not entirely clear
my $timezones = "Q0VUAAAKAAMAAA4QQ0VTVAADAAIAABwg";
+ #Set timezone from attribute
+ #All strings are taken from MAX! software network analysis
+ #Base64 hex decode of the CET strings gives eg.
+ #CET[00][00][0a][00][03][00][00][0e][10]CEST[00][03][00][02][00][00][1c][20] for DST
+ #CET[00][00][0a][00][03][00][00][0e][10]CEST[00][03][00][02][00][00][0e][10] for no DST
+ #bytes 10-11 and 22-23 of each string appear to represent time offset from UTC in seconds
+ #a guess is that bytes 5 & 17 represent month no.
+ #All strings below appear to follow the same pattern & identical except for name & offset.
+ #The currently set string appears at the end of the decoded C: device message for the Cube
+ if (AttrVal($hash->{NAME},"timezone","") ne "") {
+ my %tz_list = ( #timezone & strings
+ "GMT-BST" => "R01UAAAKAAMAAAAAQlNUAAADAAIAAA4Q", #DST strings
+ "CET-CEST" => "Q0VUAAAKAAMAAA4QQ0VTVAADAAIAABwg",
+ "EET-EEST" => "RUVUAAAKAAMAABwgRUVTVAADAAIAACow",
+ "FET-FEST" => "RkVUAAAKAAMAACowRkVTVAADAAIAACow", #No DST for this region or next
+ "MSK-MSD" => "TVNLAAAKAAMAADhATVNEAAADAAIAADhA",
+ "GMT" => "R01UAAAKAAMAAAAAQlNUAAADAAIAAAAA", #No DST strings
+ "CET" => "Q0VUAAAKAAMAAA4QQ0VTVAADAAIAAA4Q",
+ "EET" => "RUVUAAAKAAMAABwgRUVTVAADAAIAABwg"
+ );
+
+ my $k = AttrVal($hash->{NAME},"timezone","");
+ Log 3, "MAX Cube time set to $k";
+ }
+
#The offset was obtained by experiment and is up to 1 minute, I don't know exactly what
#time format the cube uses. Something based on ntp I guess. Maybe this only works in GMT+1?
- my $time = time()-946684774;
+
+ #From various sources Cube base time is year 2000, offset should perhaps be number
+ #of secs diff between 1/Jan/1970 and 1/Jan/2000 ie. 946684800, ie. 26 secs diff
+ #Occasional 1 min diffs seen in logs when close to minute rollover - not changed
+ my $time = time()-946684774; #additional timezone offset here for other zones is not required, clock set correctly from timezone string
my $rmsg = "v:".$timezones.",".sprintf("%08x",$time);
my $ret = MAXLAN_Write($hash,$rmsg, "A:");
$hash->{clockset} = 1;
@@ -870,7 +900,7 @@
<li>raw <data><br>
Sends the raw <data> to the cube.</li>
<li>clock<br>
- Sets the internal clock in the cube to the current system time of fhem's machine. You can add<br>
+ Sets the internal clock in the cube to the current system time of fhem's machine (uses timezone attribute if set). You can add<br>
<code>attr ml set-clock-on-init</code><br>
to your fhem.cfg to do this automatically on startup.</li>
<li>factorReset<br>
@@ -898,6 +928,23 @@
<li><a href="#attrdummy">dummy</a></li>
<li><a href="#loglevel">loglevel</a></li>
<li><a href="#addvaltrigger">addvaltrigger</a></li>
+ <li>timezone<br>
+ (Default: CET-CEST). Set MAX Cube timezone (requires "set clock" to take effect).<br>
+ <b>NB.</b>Cube time and cubeTimeDifference will not change until Cube next connects.<br>
+ <ul>
+ <li>GMT-BST - (UTC +0, UTC+1)</li>
+ <li>CET-CEST - (UTC +1, UTC+2)</li>
+ <li>EET-EEST - (UTC +2, UTC+3)</li>
+ <li>FET-FEST - (UTC +3)</li>
+ <li>MSK-MSD - (UTC +4)</li>
+ </ul>
+ The following are settings with no DST (daylight saving time)
+ <ul>
+ <li>GMT - (UTC +0)</li>
+ <li>CET - (UTC +1)</li>
+ <li>EET - (UTC +2)</li>
+ </ul>
+ </li>
</ul>
</ul>
My findings are only the result of a little playing around - nothing compared to the work that went in to create the original modules, many thanks for that.
The use of the variables may be to do with my perl abilities but I think it's correct - comments and corrections welcome
%tz_list is created and used only if the timezone attr is set, otherwise the default string in your original code is used.
AttrVal($hash->{NAME},"timezone","") same as above simply to log the human readable timezone if set
Can you quote the line where tz_list is _used_?
My apologies. I seem to have lost a line there and could not see despite looking at it many times :-\
Here is my current version, it differs additionally in that I have also set
my $time = time()-946684800;
I have seen no 1 minute time diffs since
--- /home/fruit/Manuals/fhem/Tar/fhem/FHEM/00_MAXLAN.pm 2013-12-31 03:11:18.000000000 +0000
+++ /home/fruit/tmp/00_MAXLAN.pm 2014-03-20 06:50:10.745336583 +0000
@@ -51,7 +51,8 @@
$hash->{DefFn} = "MAXLAN_Define";
$hash->{UndefFn} = "MAXLAN_Undef";
$hash->{AttrList}= "do_not_notify:1,0 dummy:1,0 set-clock-on-init:1,0 " .
- "loglevel:0,1,2,3,4,5,6 addvaltrigger ";
+ "loglevel:0,1,2,3,4,5,6 addvaltrigger " .
+ "timezone:CET-CEST,GMT-BST,EET-EEST,FET-FEST,MSK-MSD,GMT,CET,EET";
}
#####################################
@@ -215,9 +216,40 @@
#This encodes the winter/summer timezones, its meaning is not entirely clear
my $timezones = "Q0VUAAAKAAMAAA4QQ0VTVAADAAIAABwg";
+ #Set timezone from attribute
+ #All strings are taken from MAX! software network analysis
+ #Base64 hex decode of the CET strings gives eg.
+ #CET[00][00][0a][00][03][00][00][0e][10]CEST[00][03][00][02][00][00][1c][20] for DST
+ #CET[00][00][0a][00][03][00][00][0e][10]CEST[00][03][00][02][00][00][0e][10] for no DST
+ #bytes 10-11 and 22-23 of each string appear to represent time offset from UTC in seconds
+ #a guess is that bytes 5 & 17 represent month no.
+ #All strings below appear to follow the same pattern & identical except for name & offset.
+ #The currently set string appears at the end of the decoded C: device message for the Cube
+ if (AttrVal($hash->{NAME},"timezone","") ne "") {
+ my %tz_list = ( #timezone & strings
+ "GMT-BST" => "R01UAAAKAAMAAAAAQlNUAAADAAIAAA4Q", #DST strings
+ "CET-CEST" => "Q0VUAAAKAAMAAA4QQ0VTVAADAAIAABwg",
+ "EET-EEST" => "RUVUAAAKAAMAABwgRUVTVAADAAIAACow",
+ "FET-FEST" => "RkVUAAAKAAMAACowRkVTVAADAAIAACow", #No DST for this region or next
+ "MSK-MSD" => "TVNLAAAKAAMAADhATVNEAAADAAIAADhA",
+ "GMT" => "R01UAAAKAAMAAAAAQlNUAAADAAIAAAAA", #No DST strings
+ "CET" => "Q0VUAAAKAAMAAA4QQ0VTVAADAAIAAA4Q",
+ "EET" => "RUVUAAAKAAMAABwgRUVTVAADAAIAABwg"
+ );
+
+ my $k = AttrVal($hash->{NAME},"timezone","");
+ $timezones = $tz_list{$k};
+ Log 3, "MAX Cube time set to $k";
+ }
+
#The offset was obtained by experiment and is up to 1 minute, I don't know exactly what
#time format the cube uses. Something based on ntp I guess. Maybe this only works in GMT+1?
- my $time = time()-946684774;
+
+ #From various sources Cube base time is year 2000, offset should perhaps be number
+ #of secs diff between 1/Jan/1970 and 1/Jan/2000 ie. 946684800, ie. 26 secs diff
+ #Occasional 1 min diffs seen in logs when close to minute rollover
+# my $time = time()-946684774;
+ my $time = time()-946684800; #additional timezone offset here for other zones is not required, clock set correctly from timezone string
my $rmsg = "v:".$timezones.",".sprintf("%08x",$time);
my $ret = MAXLAN_Write($hash,$rmsg, "A:");
$hash->{clockset} = 1;
@@ -870,7 +902,7 @@
<li>raw <data><br>
Sends the raw <data> to the cube.</li>
<li>clock<br>
- Sets the internal clock in the cube to the current system time of fhem's machine. You can add<br>
+ Sets the internal clock in the cube to the current system time of fhem's machine (uses timezone attribute if set). You can add<br>
<code>attr ml set-clock-on-init</code><br>
to your fhem.cfg to do this automatically on startup.</li>
<li>factorReset<br>
@@ -898,6 +930,23 @@
<li><a href="#attrdummy">dummy</a></li>
<li><a href="#loglevel">loglevel</a></li>
<li><a href="#addvaltrigger">addvaltrigger</a></li>
+ <li>timezone<br>
+ (Default: CET-CEST). Set MAX Cube timezone (requires "set clock" to take effect).<br>
+ <b>NB.</b>Cube time and cubeTimeDifference will not change until Cube next connects.<br>
+ <ul>
+ <li>GMT-BST - (UTC +0, UTC+1)</li>
+ <li>CET-CEST - (UTC +1, UTC+2)</li>
+ <li>EET-EEST - (UTC +2, UTC+3)</li>
+ <li>FET-FEST - (UTC +3)</li>
+ <li>MSK-MSD - (UTC +4)</li>
+ </ul>
+ The following are settings with no DST (daylight saving time)
+ <ul>
+ <li>GMT - (UTC +0)</li>
+ <li>CET - (UTC +1)</li>
+ <li>EET - (UTC +2)</li>
+ </ul>
+ </li>
</ul>
</ul>
I just commited your patch with minor modifications. Please check if it is still working. (Will be available on fhemupdate tomorrow)
Yes, it's working fine here thanks - thanks for tidying the code up too.