GrandWizard wrote:I don't think there is an equivalent service on Honeywell, otherwise it would already be available.
In regards to adding automatic time updates to Honeywell panels, you could send:
<master code> #63 *HHMM<1 for PM/2 for AM>YYMMDD*
or
1234#63*01471160427*
At the moment the last asterisk is pressed, I noticed it sets the time requested and also resets the seconds to zero. So in the example above, exactly when the last asterisk is sent, the time is set to 1:47:00 PM.
This seems good enough to keep an alarm panel in sync, can you take a look if the above is feasible to implement for the Honeywell panels? It would be a great feature, and eliminate the clock from drifting.
Your solution works but would require us to store the customer's master code which isn't going to happen.
This comes up in meetings now and then and involves our current policy of never recording or storing user codes for privacy and security reasons.
Even on the DSC side of things, there is an option to remotely control users and their codes but this requires the master code. We have to ask users for their master code every time they sync-up with the panel as we can't store it on the server.
The primary reason for this policy is while sensitive information like passwords can be safely stored on a server in an encrypted form called a "salted hash", user codes and PIN numbers cannot as eventually they must be sent to the security panel in the normal 4-digit form.
Storing plain-text passwords or PIN numbers is probably the biggest security no-no, and hence that is why we don't do it.
GrandWizard wrote:Even on the DSC side of things, there is an option to remotely control users and their codes but this requires the master code. We have to ask users for their master code every time they sync-up with the panel as we can't store it on the server.
The primary reason for this policy is while sensitive information like passwords can be safely stored on a server in an encrypted form called a "salted hash", user codes and PIN numbers cannot as eventually they must be sent to the security panel in the normal 4-digit form.
Perhaps a compromise can be to give the user an option to store the master password locally on the EVL module itself? That way you don't have a bunch of passwords sitting on a server. It would be a 1-way function (you can send the EVL a master password to store, but there would not be a "read stored password" function).
What is the expected precision of the time sync on DSC panels?
I've got a fairly new EVL-4. I noticed that the Time Broadcast messages were being sent about 20 seconds early until last night around 3 am, when they started being sent 40 seconds late.
Does the panel send the time broadcast right at the minute change?
Are the DSC power series clocks reasonably stable or do they drift quite a bit?
The time on DSC panels are only accurate to the minute, but have very little drift as they are mains-frequency synchronised. If your jurisdiction maintains proper AC frequency control, as most do, then you will have a very accurate clock.
If you're referring to the TPI time broadcasts then I think they send them every 2 minutes are so. You would need to talk to an Envisacor engineer to be sure.
The DSC time broadcast, when enabled, occurs every 4 minutes, at 0, 4, 8, 12, ..., minutes after the hour.
The jitter on the time broadcasts is a 2-3 second variation.
Around 3 am a few days ago, the time broadcasts went from being 20 seconds early to 40 seconds late. The timing suggests this was an Envisalink network time update. However the clock shouldn't have been far enough off at 20 seconds early to justify setting the time, given the resolution. The result is that the clock is farther out of sync now, 40 seconds late.
So this leads me to a bunch of questions:
How far off does the clock need to be for the envisalink to adjust it?
How do I tell when a clock adjustment has occurred?
Given that the DSC interface sets the time to a resolution of 1 minute, is there any effort to time the sending of the clock adjustment command to a minute boundary?
What is the typical TPI latency between when the envisalink decodes a keybus event and when it sends the TPI message?
(For what it is worth, I'm looking at the time because I noticed while trying to track down some issues with the GSM communicator that the daily test call time could vary by several minutes each day. I was hoping to be able to figure out from the CSM logs how many retries were necessary. But it is hard to tell if the clocks don't seem to be stable/accurate. )
I should have added, given that the panel clock is only available to the minute, then the behavior makes sense, 20 seconds ahead was the wrong minute, so I can see that triggering a time update. I suppose the best a time update from the envisalink can do is set the panel to be between 0 and 59 seconds late.
rct wrote:I should have added, given that the panel clock is only available to the minute, then the behavior makes sense, 20 seconds ahead was the wrong minute, so I can see that triggering a time update. I suppose the best a time update from the envisalink can do is set the panel to be between 0 and 59 seconds late.
You got it. While the panel obviously is keeping time to the second, we can only control it to the minute. So, as you say, the time can be off by as much as 59 seconds.
For this reason we don't use panel time for any of our envisalerts operations. We use network time in UNIX epoch. So if you see an event in your log, that is accurate to the second as it is not using panel time.
The main reason we update the panel time from the network is to keep the clock on the LCD relatively correct and to account for DST changes, saving the home owner from having to do it themselves.
k-man, thanks for your reply. It makes sense. So the questions I had from above
[quote="rct"]
How far off does the clock need to be for the envisalink to adjust it?
How do I tell when a clock adjustment has occurred?
Given that the DSC interface sets the time to a resolution of 1 minute, is there any effort to time the sending of the clock adjustment command to a minute boundary?
What is the typical TPI latency between when the envisalink decodes a keybus event and when it sends the TPI message?
As far as the first question, sounds like if the minute is off by one it will trigger an adjustment, so the panel's clock should be at most 1 minute behind actual time as seen by the envisalink.