-
22nd July 2011, 10:08 PM
#1
Automated Home Sr Member
DFP refresh/update slow
Hello,
Is it just me or are the DFP's slow to update their display/respond to button presses and even play sounds?
Is there anyway to make things quicker? Buttons and display arn't that important, but when pressing for intercom or more importantly playing a sound, theres a good 2 - 2.5 second delay. I.e. the doorbell gets pressed, theres a good delay before the sound is played. Another example is just having a sound played when say a door opens.
-
25th July 2011, 09:53 PM
#2
-
26th July 2011, 06:01 PM
#3
Automated Home Sr Member
Hmm I'm running server 2003...
It seems the actual DFP comes to life to play the sound almost instantly (You can hear the speaker has come to life) but the actual sound takes a long time to play - once played the speaker goes off straight after.
I'm not sure how to work out what is causing the delay?
-
27th July 2011, 09:13 AM
#4
Automated Home Legend
-
27th July 2011, 11:17 AM
#5
Automated Home Ninja
You can try and see what is taking place when you open a door by capturing the logging to file.
In the following I opened my front door, it played a 'Ding' and then I closed the door.
I then went to Cortex | Tools | Logging | Capture current communications history to log file now!
Then I clicked View Log file.
Here is an extract that I have annotated.
10:44:41:140 < 91062000BA0C0481 * A packet comes in because the door is opened
10:44:41:156 < Mouse trap * It is from a DIO module with 8 inputs
10:44:41:171 < Central Heating Pressure
10:44:41:203 < Hall PIR 2
10:44:41:203 < Porch PIR
10:44:41:218 < Key fob 1
10:44:41:234 < Key fob 2
10:44:41:312 < Remote Temperature * A temperature packet comes in whilst
10:44:41:875 < 91060FF8BA00025A * processing the above
10:44:41:906 < Front Door Bell
10:44:41:906 < Front Door * This is the cause of packet i.e. door opening
10:44:42:140 > All Intercom * Intercoms are turned on
10:44:42:156 > FF09112030006208002602
10:44:42:203 < 1820300169
10:44:42:281 < 180062017B
10:44:42:281 > Sound * Sound opject switches on audio bus in PCA
10:44:42:296 > 2601
10:44:42:312 < 1820300169
10:44:42:343 > All Button * LED's on panels get turned on
10:44:42:359 > FF0A112030002A08003C0105
10:44:42:390 < 1820300169
10:44:42:406 < 18002A0143
10:44:42:421 > All Button
10:44:42:437 > FF0B112030002B08003C010404
10:44:42:468 < 1820300169
10:44:42:484 < 18002B0144
10:44:42:734 MediaPlayer: Start DING.WAV * PC plays Ding
10:44:43:625 MediaPlayer: Stopped
10:44:43:656 T> OnPlayDone * Internal message to Telephone
10:44:43:656 > All Intercom * Intercoms going off
10:44:43:671 > FF09112030006108002603
10:44:43:703 < 1820300169
10:44:43:718 < 180061017A
10:44:43:734 > Sound * Audio bus gets switched off
10:44:43:750 > 2600
10:44:43:765 < 1820300169
10:44:43:781 > All Button * LED's off
10:44:43:796 > FF0A112030002A08003C0205
10:44:43:843 < 91062000BA08047D * Door Closes
10:44:43:859 < Mouse trap
10:44:43:859 < Central Heating Pressure
So what does this show?
From door opening to sound playing was about 1.6 seconds.
> arrow is packets going out
< arrow is packet coming in
Depending on the system configuration other 'things' may be going on.
What is logged is dependant on options set.
Logging 'Lots' of things (see logging diagnostics) slows the system down.
Having the Communications window visible slows the system down.
But not by much.
Viv.
-
27th July 2011, 11:54 AM
#6
Automated Home Legend
how about introducing, say, a user-defined Priority 0 possibility, which always goes first ?
There could be many situations where this might be useful, and work well, if not overdone ...
especially in association with selected buttons & PIRs & digital inputs ...
seems unlikely such queue jumping would happen often enough to upset the greater scheme of things ...
we have several situations where it would be appreciated (eg: Varilight SD lamp dimming, issuing stop commands, switching things that should run for only short bursts) ...
how about it ?
-
27th July 2011, 02:38 PM
#7
Automated Home Ninja
...especially in association with selected buttons & PIRs & digital inputs ...
All incoming packets are processed immediately independant of the routine processing that ever object gets multiple times per second.
It is the output packets that are prioritised. Lights and relay actuation have the highest priority.
-
27th July 2011, 03:12 PM
#8
Automated Home Legend
yep, appreciate that - of course it's the consequences of chosen triggers that would want the priority ...
hmm, lights & relays might cover it for us, though, so thanks ...
NB: we haven't yet quite finished wiring up ... fourteen modules now installed, though, but none of them yet activated, so 'have yet to find whether we have timing issues or not !
Last edited by chris_j_hunter; 27th July 2011 at 03:15 PM.
-
5th August 2011, 10:38 AM
#9
Automated Home Sr Member
Thanks Viv
I will look at this log tonight and see where the slow down is happening.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules