Hi Scott,
I upgraded to your latest and greatest last week - thanks for all your hard work!
I was wondering though if you were aware if any of the changes you've implemented in 3.0 could be the cause of a noticeable performance drop in Housebot to event responses. I've noticed that lights that previously came on within a second or so after a Passive IR was tripped are now consistently taking 4.5 seconds. This may not sound like a big deal, but it makes a huge difference if you're relying on the lights coming on automatically for a room - 1.5 seconds is perfect but 4 seconds just doesn't cut it, and you instinctively reach for the light switch.
It seems I'm getting similar response delays to Software Remote button-presses that cause tasks to run. I'm rather curious and was wondering if perhaps had any ideas?
HouseBot 3.0 Performance?
-
Richard Naninck
- HouseBot Guru Extraordinaire
- Posts: 1121
- Joined: Tue Sep 28, 2004 7:49 am
- Location: The Netherlands
I don't see that at all.
While pressing an X10 theme light button, my lights switch on within the 1.5 seconds you described.
Just tested the receive part by looking at the X10 controller and it takes about 3 seconds to receive and process data sent by an X10 remote, received and transmitted through the line via the TM12 or 13 and then being received by the CM11 and displayed in HB.
I am not sure if this was anything quicker in V2. Which device do you use to receive the sensors? I have good experiences using a W800. It skips the TM12 and CM11 and makes receiving almost instant.
While pressing an X10 theme light button, my lights switch on within the 1.5 seconds you described.
Just tested the receive part by looking at the X10 controller and it takes about 3 seconds to receive and process data sent by an X10 remote, received and transmitted through the line via the TM12 or 13 and then being received by the CM11 and displayed in HB.
I am not sure if this was anything quicker in V2. Which device do you use to receive the sensors? I have good experiences using a W800. It skips the TM12 and CM11 and makes receiving almost instant.
There is nothing specifically new to V3 that should cause slower X10, IR, or SWRemote responses. It's possible that something somewhere changed and it is having an effect on your entire system, but it's hard to guess what that might be.
You might want to create a log and trace all property value changes that you are suspicious about into the log. Maybe you can see a pattern that could help narrow the issue down.
You might want to create a log and trace all property value changes that you are suspicious about into the log. Maybe you can see a pattern that could help narrow the issue down.
Scott
I have been working at narrowing this down and can now confirm that the delay occurs on tasks that fire "when conditions are met" - in version 3 there is now a 2 or 3 second delay before the task, for which a condition comes true, actually runs.
I have downgraded back to Housebot 2.32 and can confirm that this delay does not exist on 2.32.
For example, I have the following task that fires "when conditions are met":
If ('PIR Pantry.Power State' is Equal 'On') Then
Change 'Pantry2.Leviton Dim Level' to '100'
'PIR Pantry' is a SmartHouse MS14 Passive IR transmitter and it's signal is received by a W800 receiver connected via serial port to the HouseBot server. 'PIR Pantry' is configured as an X10 transmitter in HouseBot.
I noticed that in 3.00, the "Last Executed" value for the above Task shows between 2 and 3 seconds AFTER the value of 'PIR Pantry.Power State' changes to 'On'. It seems that there is now (in 3.00), some delay in the "When conditions are met" processing that isn't there in 2.32. As a result, in 3.00, the pantry light now takes around 4 seconds to come on, where in 2.32, it takes about 1 second.
This delay may not seem like much, but it makes the world of difference when switching on lights automatically as people enter rooms - the 2 or 3 second delay means lights only come on 4 seconds after entering the room, by which time, the user has reached for the light switch...
Since I have downgraded to 2.32, yesterday morning, the problem has gone away.
I hope you may be able to use this information to identify the cause of the problem in 3.00 - I like the colour-change feature you've introduced for buttons in remotes, and would certainly like to know that HouseBot remains such a brilliant product and does not start experiencing performance problems.
I have downgraded back to Housebot 2.32 and can confirm that this delay does not exist on 2.32.
For example, I have the following task that fires "when conditions are met":
If ('PIR Pantry.Power State' is Equal 'On') Then
Change 'Pantry2.Leviton Dim Level' to '100'
'PIR Pantry' is a SmartHouse MS14 Passive IR transmitter and it's signal is received by a W800 receiver connected via serial port to the HouseBot server. 'PIR Pantry' is configured as an X10 transmitter in HouseBot.
I noticed that in 3.00, the "Last Executed" value for the above Task shows between 2 and 3 seconds AFTER the value of 'PIR Pantry.Power State' changes to 'On'. It seems that there is now (in 3.00), some delay in the "When conditions are met" processing that isn't there in 2.32. As a result, in 3.00, the pantry light now takes around 4 seconds to come on, where in 2.32, it takes about 1 second.
This delay may not seem like much, but it makes the world of difference when switching on lights automatically as people enter rooms - the 2 or 3 second delay means lights only come on 4 seconds after entering the room, by which time, the user has reached for the light switch...
Since I have downgraded to 2.32, yesterday morning, the problem has gone away.
I hope you may be able to use this information to identify the cause of the problem in 3.00 - I like the colour-change feature you've introduced for buttons in remotes, and would certainly like to know that HouseBot remains such a brilliant product and does not start experiencing performance problems.
Do all of your Tasks that are set as 'when conditions are met' do this, or is it specific to just this one. If it's just this one, I would suspect something like the hardware interface plugin(s) that are attached to the 'PIR Pantry' device or the 'Pantry2' device. Which Hardware Interface(s) are used with those two devices? You may want to run an hardware interface trace to see if that shows anything.
Scott
It's all of them. What is interesting is that I can duplicate the delay by manually changing the "Power State" property of the triggering device in Housebot itself so that the condition becomes "met", so it does not appear to be related to the W800 receiving hardware.
For example, I can use the main Housebot application interface to open the PIR Pantry (or other triggering device, such as wall switch, door sensor), and manually change the Power State to "On", at a particular time, e.g. 10:00:00 am.
The Power State history for the device will show that the state changed to on at exactly that time. However, the Task will show "Last Executed" at 10:00:03 am, and the light Leviton Dim Level's history will show it was changed at 10:00:04 am.
Hope this helps!
For example, I can use the main Housebot application interface to open the PIR Pantry (or other triggering device, such as wall switch, door sensor), and manually change the Power State to "On", at a particular time, e.g. 10:00:00 am.
The Power State history for the device will show that the state changed to on at exactly that time. However, the Task will show "Last Executed" at 10:00:03 am, and the light Leviton Dim Level's history will show it was changed at 10:00:04 am.
Hope this helps!
-
Richard Naninck
- HouseBot Guru Extraordinaire
- Posts: 1121
- Joined: Tue Sep 28, 2004 7:49 am
- Location: The Netherlands
Don't want to interfere, but this got me curious.
What happens on condition based tasks that don't address X10 stuff at all.
Something like: If system time = 10:00:00 then set timer.Running to Yes.
It would only require create a timer for test purposes and maybe you have other devices and properties not related to X10 that can be used for this test.
What happens on condition based tasks that don't address X10 stuff at all.
Something like: If system time = 10:00:00 then set timer.Running to Yes.
It would only require create a timer for test purposes and maybe you have other devices and properties not related to X10 that can be used for this test.
There is potential for up to a 2 second delay in executing a Task, but it would only come into play if that same task was currently executing. Multiple instances of the same Task are not allowed to run, so if a Task block within the Task is currently running and the Task is called to run again, it will check every 100 ms for 2 seconds to see if the running Task block has completed before running (or aborting).
However, this doesn't really sound like your case. And there were no changes to this logic for V3. I can't think of any changes to the Task logic for a long long time, so I keep thinking it might be related to something else. Like there were changes to the W800 hardware interface to better handle cases where X10 commands were sent and received over and over.
Maybe try and run the old (V2.x) W800 hardware interface plugin in your V3 setup and see if that makes a difference.
However, this doesn't really sound like your case. And there were no changes to this logic for V3. I can't think of any changes to the Task logic for a long long time, so I keep thinking it might be related to something else. Like there were changes to the W800 hardware interface to better handle cases where X10 commands were sent and received over and over.
Maybe try and run the old (V2.x) W800 hardware interface plugin in your V3 setup and see if that makes a difference.
Scott
I ran into a situation like you describe with a task taking a while to execute. What I found was that I had a couple of script devices that were always running and sleeping 10 milliseconds during every poll of a property that would tell the scripts that there was something to do. It seems that this activity was preempting the conditional tasks to some degree. I would see the 4-5 second delay before those task would fire when the property changed that they were waiting on.
I changed my polling delay to 50 milliseconds per loop and the problem seemed to go away. It would be interesting to know if there is a recommeded value for this to balance out responsivness of the script device task vs. starving other built in tasks.
Maybe something changed in this area between 2.x and 3.x.
I changed my polling delay to 50 milliseconds per loop and the problem seemed to go away. It would be interesting to know if there is a recommeded value for this to balance out responsivness of the script device task vs. starving other built in tasks.
Maybe something changed in this area between 2.x and 3.x.