Here we go again...

I've just updated to the very latest versions of toolkit & PICED, and done a firmware update in Wiser to Kona_1.21.0

I remember having exactly this same problem back in April, and as I recall the ONLY way I could figure out to bend this stubborn swine to my will was to LIE to the unit and say I was in some other country where the time is an hour behind the UK...

We've just changed into daylight savings time here in the UK, so the clock in Wiser needs to go back an hour...

IT ABSO-BLOODY-LUTELY WILL NOT STAY AT THE TIME I SET!!! ****

GRRRRR..... THIS IS *** SO *** INFURIATING!!!!!

Firstly that it didn't automatically change to the correct time, and secondly because every time I try to set the clock in the Wiser UI, it just re-sets it straight back again... It's doubly irritating that I posted more or less exactly this same error 6 months ago and this bug STILL hasn't been fixed.

I've just adjusted every other clock in the house in 5 minutes flat, yet here I am once again fighting this bl**dy expensive device to get it to do so simple a task that even a 99p digital clock does a better job of it...

As it was such a long time ago, I can't actually remember how/where I set the timezone information, so I'd appreciate a bit of a nudge in the right direction...

TIA

Paul G. (AKA the Ranting man)

 

Not so sure...

Yup, I just noticed I had a private message sitting in my inbox with detailed instructions for how to filter out the CBUS date & time messages from interfering with Comfort. I'll implement that ASAP, which should isolate Comforts' date/time from being "munged" by CBUS - since Comfort is where I tend to do most of my scheduling this at least alleviate most if not all the noticable problems I get with all my events firing 1 hour early...

However, I'm still not convinced that it is actually a problem on the Comfort side, - as is suggested in the aforementioned message...

What I'm seeing looks more to me like Wiser is overriding the time I set with the time retrieved via NTP - I currently have the wiser set to get time from NTP... - I shall (when I figure out where the config setting is again!) try turning that off & see if my time will then "stick"...

Comfort doesn't have any internal method of acquiring its own time, - the DST offset is implemented as an internal event that AFAIK just increments or decrements whatever the RTC date/time is... If I set Comforts clock via the management PC, it will (if it's disconnected from CBUS) quite happily accept whatever date/time I say it is...

I believe - based on what I'm observing that it is CBUS that is setting Comforts clock wrongly, - not the other way around... Perhaps this isn't the case, but the symptoms certainly look like this... (Plus I've had Comfort in situ for over 10 years and I've *NEVER* had a single problem with its timekeeping until I added a Wiser unit onto the CBUS network about 9 months ago).

Surely what *should* happen, is that Wiser gets its time in UTC from the internet via NTP, then, using the location information I've provided about what timezone I'm in, apply the appropriate offset to the UTC time to get my correct local time?... It looks for all the world like that algorythm is FUBAR in Wiser, and it is not applying the correct offset. - hence I recall I "fixed" this last time by lying about what timezone I'm in, so rather than saying I'm in GMT (or BST), I said I'm in Helsinki or somewhere that is normally 1 hour behind the UK.

In Wiser, I can enable/disable the "Apply daylight savings" checkbox on the set CBUS date/Time screen, and it does change the hour, - but it's still always too far advanced, so when I enable it, the hour advances by 1 (as you'd expect), but it is then 2 hours out!

I think I need to try disabling the acquisition of time from an external NTP timesource, and then just manually set it, and hope that it stays at the time I enter...

Cheers.

Paul G.

 

Thanks Nick

Ah, OK, that sounds feasible... - could explain why I never had any issues with Comfort's timekeeping until the Wiser came online... - could be the combination of the interaction between them I guess, hence making it look like the Wiser is to blame...

Perhaps I am being unduly harsh on CBUS?!?!?

I have the instructions for preventing the time broadcasts across the UCM between CBUS & Comfort, so hopefully that will resolve this for good... - I'll implement that as soon as I can get to it...

I'll post back here when I have some results to report...

Many thanks!

Paul G.

 

Wiser Time Sync Issue

Hi Paul,

I have received my second Wiser after fighting with the first one. As it turns out the second one is doing the exact same thing. I read your comment on not having a time sync issue prior to adding the Wiser and now you have an issue.

I cannot get this Wiser to keep the correct time, whether I set it to use NTP server or not, it never syncs to my time zone. I have not been able to get an answer to what the problem is. I have been working with Tech support and have no solution thus far.

I only have two relay modules, power supply and a 8 button keypad. I am trying to use the Wiser for scheduling. How are hard can this be to set?

I am using the latest PICED and newest firmware 1.21 that comes with PICED. I believe there is an issue with the Wiser/Piced/Firmware. One or all three of these items.

Carmelo

 

Not just me then!

Do you also have Comfort Carmelo? - current assertions being made here are that it is the Comfort time keeping that is actually to blame, - although I've always been sceptical of that idea, but I have seen enough weird errors over the years that have turned out to have really unexpected causes, so I'm prepared to give anyone the benefit of doubt until proven otherwise...

However, as if to now add more fuel to the fire, last night I implemented the change that had been suggested to filter out the time broadcasts across the Comfort UCM, (the 1st screenshot shows that config). This has had the effect of isolating the time settings between CBUS & Comfort, - I now can (and have) set the time explicitly on the Comfort panel, and this is now staying at the correct time that I set - whereas before, it would re-sync to the wrong time provided by CBUS. So at least now I can keep the correct time in Comfort, which is 80% of the battle won for me (since that's where I do my scheduling).

However, Wiser *STILL* keeps changing its time back within seconds of me setting it, so it is DEFINITELY NOT Comfort that is causing CBUS to incorrectly sync its time... so let's put that idea to bed shall we, and concentrate on where the bug *really* lies...

Note that I still have Wiser set to sync with NTP so it could be that causing this behaviour? (which is what I suspected all along). - For the life of me I couldn't find the option anywhere in the Wiser's two UI's for changing that, - I know I've done it before! - could someone please chime in & remind me exactly where in the interface I configure the NTP time-sync option?

The series of screenshots show the process I am using to set the Wiser time, - just in case I'm missing something really obvious that anyone could point out ...
1) Connect to the Wiser UI
2) Go into the settings page (spanner & screwdriver icon)
3) Click the CBUS Date & Time button
4) Observe that the time is currently 1 hour ahead of correct, so I change the hour by clicking the down arrow beneath it
5) once I've made a change, the green "Set" button becomes active, so I click on it. (once pressed, it "dims" again)
6) Observe..... a few seconds later (it's probably quicker, but delayed by the web page refresh) the time goes right back to what it was before, and is thus back to being an hour ahead of correct again.
7) Shout, swear, and generally curse CBUS!

So, there is to my mind, now that Comfort has been eliminated; (throughout the entire of the above excercise, Comfort's time remained correct), no doubt that there is a bug in the Wiser's timekeeping implementation.. So C'mon Clipsal, man up and admit it, - Steve Jobs was big enough to admit a DST bug in the iPhone this week, (and promise a fix within weeks), why can't you guys do the same? - bearing in mind I've paid a *lot* more for my CBUS implementation than I did for my iPhone!

Over to you guys!

 

I'm a bit confused too now.. I don't have Comfort but I have a colour C-Touch and a Wiser. When I just checked my C-Bus time was out by an hour and 10 minutes :-( so I just corrected it via the UI in Wiser and the C-Touch stopped working and then restarted HomeGate shortly afterwards.

Anyway they both then showed the same time but it isn't NTP synched time as it is a couple of mins different to a current synch on the PC. It does hold however it isn't jumping forward an hour again.

So... where is the 'synch to NTP' option in Wiser and which should be my definitive time source on C-Bus - does the colour C-Touch use NTP too ? I assume because of the accuracy arbitration it will/should be an NTP source.

Why when I change times on Wiser does the CTouch hang (button beeps but no results) and then a minute or so later reboot HomeGate ?

When I look on the Wiser web page I see this...

Time Source Slave at 02/11/2010 17:30

...so I assume that's synched to something else, maybe C-Touch ? But the time was just altered on that because I manually changed it from Wiser....and it's a couple of minutes wrong from an NTP synched source.

K

 

I haven't read thru all the postings but I don't understand your assumption above about "wrong from an NTP synced source". "Time Source Slave" means that your Wiser does _not_ have an NTP connection and is therefore a slave to any device that provides time on C-Bus. If that device doesn't have ntp sync than your time is not ntp synced. For example, my Wiser currently says: "NTP Master at 02/11/2010 12:07:01 HG-LAN Enabled, Schedules Enabled" because it has NTP sync. A common mistake that I tend to make is to forget to set the gateway IP in my project (PICED->Project Details->IP) when I setup the Wiser as a LAN device (rather than a router). When that happens, the Wiser can't synchronize with NTP and thus becomes a slave which on my network means that it will pick up time from a black-n-white CTouch which does not have ntp sync so the time will slowly drift from NTP time.

 

Thanks Nick

PS - that wasn't intended as a dig...

I'll sort out some diagnostic logs in the next day or two..

In the meantime, is there somewhere I can read up & get a better understanding of just exactly how CBUS implements time, time synchronisation, the time hierarchy and so on...

I come from an IT background, & work a lot with Active Directory and have a fairly full understanding of how time synchronisation works in that environment... I guess I kind of expected certain behaviour to work the same (or similar). I'm used to all this kind of stuff working in a predictable and deterministic way, knowing the what's/why's & wherefore's of whatever behaviour I'm observing, and most importantly being able to control it! - In my world it's a fairly cut & dry process for me to set the authoritive time sync master...

Thanks

Paul G.

 

Sorry ...I phrased it badly.. What I was trying to say was 'compared with' an NTP source ie 'from' another known synched source.

Can I manually turn the NTP synch on and off in Wiser ?
edit: Found this in the Wiser tab in Project options in PICED (it is set for me)

and if I manually set the time in Wiser using the UI does it unset NTP ?

Reason I ask is that I thought I had NTP synch previously and now I don't. Gateway IP is correct and I haven't updated the Wiser recently.
(in the LAN tab under use Wiser as LAN device I do have the correct gateway address entered)

edit: I just rebooted the Wiser (pulled psu) and now I have NTP synch and my time is correct for the new GMT - and stays that way (not jumping forward an hour). - I didn't PICED download anything . Not sure how/why it lost its NTP lock, unless it's by the manual time change I did in the Wiser UI.

Does colour CTouch have NTP ?

K

 

Hi Paul....In the public C-Bus serial protocols section there are all the gory details for the clock and timekeeping application - it's a pretty heavy read as it is quite sophisticated...

K

 

I have just been directed to this issue (representing Comfort technical suppport). Although it was mentioned that this is a "known issue" with Comfort, nobody has given us this feedback before.

Comfort sends a message to Cbus to update the time and date with the DST offset =0 ie this field is basically ignored. Hence even when there is daylight saving, the DST field would be 0. Do you mean that Wiser will change the clock as if no DST change is applied?

This does not seem to be the cause of the problem here because at this time of the year in the UK where pgordon lives daylight saving is over so the time sent by Comfort with DST=0 would be correct and so should not be causing the wrong time in Cbus

 

slychiu - I think you guys need to re-read the CBUS clock and timekeeping specification.

DST = 0 does not mean ignore this field it means no daylight savings. Also this message was first posted immediately after the clocks changed in the UK.

The problem is happening when the times cut over and the two masters fight with each other I guess.

Regards
Mark

 

Hi Chiu,

Here are some notes I had made about in April that may be of use:

With no Wiser connected on the C-Bus network, just 2 CNIs, one used
for devkit and the other just sitting on its own, and a Minder Pro. If
I use devkit to set DST, then Minder Pro overwrites the DST setting.
Here's the devkit log: (Source unit 10 is the Minder Pro)

DevKit (setting DST and time on C-Bus)
14:16:20 Tx : \05DF000D010E101401<CR>
14:16:20 Tx : = Multipoint, Time 14:16:20 Daylight Savings Offset: 1 hour(s)
14:16:20 Rx : 050ADF000E0207DA04080312<CR> "____________"
14:16:20 Rx : = Source Unit 10, Date Thursday 8/4/2010
14:16:20 Rx : 050ADF000D010E101400D2<CR> "___________"
14:16:20 Rx : = Source Unit 10, Time 14:16:20 Daylight Savings
Offset: 0 hour(s)

In above trace, comfort is overwriting DST in the CNI immediately after a time master (devkit in above) is setting it.

 

Thanks I can see how setting DST=0 would be a problem. This can be easily fixed in the next firmware release of the UCM/Cbus

MHeaton - thanks but I do know that DST = 0 does not mean ignore the field. It is DST=FF that means ignore the field.

However this does not explain why PGordon is having these problems in November. Presumably Wiser would be sending DST=0 so there would be no problem in the time sent by MinderPro.

 

Hi Chiu,

Thanks, I'm glad the issue has been identified. We look forward to testing with the UCM fix. Please note that you may not want to just make a change to send FF, since this means that anytime a C-Bus time master broadcasts time, Comfort will echo it back immediately with DST=FF and that would mean that Comfort is asserting that it is the time master. I think the right fix would be to match the appropriate C-Bus time protocol behavior.