| Author |
|
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 04 2007 at 22:26 | IP Logged
|
|
|
I would like to have a trigger when the Status/Level of an Insteon device is changed in the PowerHome database.
This would be useful because the Insteon Device Chg trigger does not report individual device changes for a PLC group command unless the PLC Group Cleanup option is in effect. I could query the database to find out which devices are in the group and retrieve their statuses/levels but that would not tell me if the statuses/levels changed from what they previously were and that could lead to extra processing.
Also, if the PLC missed an update message and PowerHome corrects the database status on a periodic Status Scan, the Insteon Device Chg trigger does not fire so a macro based on that trigger would not know that the status/level had changed.
The information I would like to see passed is device Id, Address, Status and Level. The trigger should not fire unless the status or level changes from what is was in the database.
I'm very impressed with PowerHome's capabilities so far.
John
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 04 2007 at 23:05 | IP Logged
|
|
|
I was just reading the "Synchronizing KeypadLincs" post by UpstateMike. Keeping the KeypadLincs' buttons synchronized is exactly what I would use this new trigger for.
One of the things I want to do is have a button on one or more KeypadLincs and/or a PowerLinc group that activates a scene. I want the button(s) to remain on as long as all devices in the scene are at the proper levels. If I see a device level change, I can query the PowerHome database to find out the other devices in the scene and then query their statuses in the database. I can then send a command to turn the corresponding KeypadLinc button(s) on or off depending on whether the scene levels match or not. I can also send a message to my Crestron home automation controller so that it can keep track of the scene status.
I currently have a Vantage lighting system for a small number of lights and it has this feature but additional Vantage equipment is pretty expensive so I am looking for something less expensive and so far Insteon looks pretty good since I can use PowerHome as the lighting controller.
The new trigger would also help with UpstateMike's problem of detecting that a SwitchLinc Timer had expired because the database change trigger would fire when PowerHome discovered the device status change during a Status Scan.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 22 2007 at 17:38 | IP Logged
|
|
|
Dave,
Your plans for this, posted in the PowerHome Bug Reports section, thread Database Status/Level Inconsistency, sounds like just what I wanted.
So for example, for a PLC group, an SQL statement would update the statuses for all of the devices in the group and then a trigger would be generated for each device whose status changed? So the database would have the new statuses for all of the devices in the group before the first trigger fired? If so, that is exactly what I need.
Thanks,
John
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 22 2007 at 18:50 | IP Logged
|
|
|
John,
Yes, this would be proposed method of implementation. This is one of the reasons I don't like to fire the trigger before the actual update...you may want to access and use the status withint the trigger or the trigger action itself.
Sooo...what should happen is that an Insteon command is received (group broadcast, etc.) that is going to cause some status change to Insteon devices (status change now includes level). PowerHome will issue the SQL command to update all necessary devices and at the same time copy the old status to the new previous stat column. At this point, the current "Insteon Device Chg" trigger will fire just as it does now. This trigger does not care if a status actually changed, just that a command was received that could potentially cause a change. Next the trigger check would be performed for all devices that ACTUALLY had a status change as determined by a difference between status and previous stat. When that trigger is executed, the plan would be to pass as extended variables (the TEMP variables) both the current status and the previous status so you wouldnt have to check the database if you didnt want to.
The only problem I have now is what to name the new trigger  . The current trigger name of "Insteon Device Chg" seems to make more sense and I should probably rename the existing trigger to something like "Insteon Device Cmd". If anybody has suggestions on what makes the most sense, please feel free to post  .
Dave.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 23 2007 at 01:25 | IP Logged
|
|
|
Dave,
I think this will be a very cool feature.
You could call it Insteon Status Chg and leave the Insteon Device Chg as it is for compatibility. Is it possible to also add the Insteon Device Cmd trigger name as a sort of alias to Insteon Device Chg since Insteon Device Cmd is more accurate?
Would the sql select statement that you would use to determine which devices had a status change use the same selection criteria as the preceding sql update statement so that status changes from previous update statements would not be picked up? Sorry if that's an obvious question but it's a concern that popped in my head.
Another piece of information to pass in the temp variables that might be useful is what sort of Insteon command caused the update. I don't have an immediate use for that but I might think of one.
Would this trigger catch the situation where the PLC missed a command or a SwitchLinc Timer expired and the status change was discovered during a Status Scan?
John
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 23 2007 at 23:17 | IP Logged
|
|
|
John,
Since the trigger is actually just a number lookup within the dropdowns table, I can make the text anything without affecting any backwards compatibility (other than the text just changes...no-one would have to make a change, it would just read differently on their screen but would still be the same trigger). Actually, anyone who was adventurous could wreak havoc in the dropdowns table and change the onscreen text to pretty much whatever they want .
I think the new naming convention is the most accurate though...Insteon Device Cmd for the existing trigger and Insteon Device Chg for the new proposed trigger.
Nope, it would be different SQL statements and they wouldnt interfere with each other. The first SQL would just determine if an Insteon command could actually effect a device...the second trigger determines if a change actually occurred.
Unfortunately, the new trigger would not have the information on what caused the status change (the actual command). However, the existing trigger already contains this information. More importantly, I could probably update the existing trigger to also pass in the previous status and the current status. The only problem though is that the trigger would still fire even if the status didnt change (such as a light receiving an "ON" command when it is already on). However, you could check for this situation in the Boolean field of the trigger and prevent it from firing if you were only interested in actual changes.
Yes...the new trigger would fire anytime the status changes (unless I make a mistake and miss something ). This would include the situation where a group command was missed by the PLC and a later status request corrects the current status.
Dave.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 24 2007 at 10:30 | IP Logged
|
|
|
Sounds good. Let me know if you need a pre-beta release tester for this feature.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 31 2007 at 15:52 | IP Logged
|
|
|
Ok,
Ive gotten to the point in my code where Ive got most of the Insteon Status changes effected and have tested the current trigger (Insteon Device Chg) with the previous status and current status.
After working through the initial bugs, this is now working great! So great, Im wondering if there is really a need for the new Insteon Device Change trigger since I believe everything required can be handled by the current Insteon Device Chg trigger (to be renamed Insteon Device Cmd trigger).
To explain a little...the current Insteon Device Chg trigger is fired anytime an Insteon command is received or sent (the bugs where it sometimes did not fire are fixed), even if that change does not result in an actual status change. As such, just having a switch remotely turned on could cause the trigger to fire a couple of times for a device (once for the group broadcast, once for the group cleanup). The current version also does not give any indication of previous or current status.
A request was made for a new Insteon trigger that essentially fired whenever status for a device (or level) changed. In order to accomplish this goal (as well as cleanup issues related to dimming to 0 showing ON, etc), changes had to be effected to the database and the general Insteon update principals. This new trigger would allow a user to select an Insteon Device and the trigger would fire when the status changes. Due to the nature of the mechanism to launch this trigger, you wouldnt have access to the actual command that caused the status change or the device that caused the status change. You would basically just have the fact that the status changed, the previous status, and the current status. Im wondering if this trigger is now necessary since all of this (and more) will now be available in the current Insteon Device Chg trigger.
The current trigger will have access to the previous status and the current status (in the [TEMP2] and [TEMP6] variables respectively) as well as access to the command that caused the status to change and the device that caused the change. You'll even be able to set this trigger up to ONLY fire when the status changes by placing "[TEMP2] <> [TEMP6]" in the Boolean field. The only advantage I see to the new trigger is that it will be simpler to setup since you don't have to type the "[TEMP2] <> [TEMP6]" in the boolean field.
Anyways, to make a long question short[er], I'd like everyone to let me know what they think. Is the existing trigger with the status change enhancements sufficient, or would you all still like to have a separate Insteon Device Chg trigger?
Thanks,
Dave.
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: January 31 2007 at 17:21 | IP Logged
|
|
|
Dave,
I think the Insteon Device Cmd trigger should do the job as long as it is clearly documented.
Tom
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 31 2007 at 17:46 | IP Logged
|
|
|
Hi Dave,
Thanks for all you have done so far.
If a PLC group command is issued and the option to issue the cleanup commands is not selected, would there be a Device Cmd trigger issued for each device affected by the group command or would it be just a single trigger saying that the group command was issued?
If the PLC missed a command or a SwitchLinc Timer expired and the status change was discovered during a Status Scan, would there be a Device Cmd trigger issued?
I personally don't have a use right now for the command that caused the status to change being part of the information passed by the proposed new Device Chg trigger but if you wanted to provide it, could you store the command info in the device's database entry so that it would be available not only to the new Device Chg trigger but also to anyone querying the database?
John
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: February 01 2007 at 14:35 | IP Logged
|
|
|
John,
If a PLC group command is issued, a trigger would be launched for each individual device within the group (as long as the device was selected in the trigger and not [Any]) instead of a single trigger being fired.
If a command was issued and missed, then yes, the trigger is fired (now, in the upcoming beta...not the current version) when status change is detected during a POLL STATUS command.
It would be possible to store the last command that caused a status change, but it would require more database changes (something I would probably hold off on for awhile) and probably wouldnt be that useful. The new proposed "Insteon Device Chg" trigger would not have access to the command anyways. It's the current (soon to be renamed) "Insteon Device Cmd" trigger that currently has access to the actual command that caused the change (but is not stored anywhere).
During my round of code changing last night though, I did come across a situation where status is changed on an Insteon device and the "Insteon Device Cmd" trigger is not called. This is when an X10 address is assigned to an Insteon Device and an X10 command changes the status. In this case, an X10 trigger would be fired (which does not have near the information and flexibility of the existing Insteon Device Cmd trigger). I guess I need to also ask if this is a problem that I need to address. For those in a pure Insteon environment, there would be no problem. But for those that primarily use Insteon and then also have X10 addresses assigned for legacy control for other hardware or software, then status on an Insteon device could be changed and the Insteon Device Cmd trigger would not fire. Instead an X10 trigger would fire without access to previous status.
Dave.
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: February 01 2007 at 14:51 | IP Logged
|
|
|
I have a mixed X10/Insteon environment, but all I'm doing with X10 now (since I replaced my 220V receptical with an Opto 22 relay and an InLineLinc) is to receive X10 Remote RF signals and catch them with PowerHome triggers to drive the Insteon stuff. None of my Insteon devices have X10 addresses. Actually, except for a couple 3-ways, I'm not doing much linking between Insteon devices either, but I am doing a lot of "additional" control through PowerHome.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: February 01 2007 at 15:16 | IP Logged
|
|
|
Hi Dave,
I am new to PowerHome so I may not be understanding the exact behavior of triggers.
What I would like to be able to do is specify one generic trigger that would fire once for each Insteon device whose status changes (passing the device Id, Address, Status), regardless of if it was caused by a group command, a switch press or because a status change was discovered during PowerHome's regular status polling.
You wrote: "If a PLC group command is issued, a trigger would be launched for each individual device within the group (as long as the device was selected in the trigger and not [Any]) instead of a single trigger being fired."
Are you saying that I would have to have a trigger defined for each device? If so, I don't think I would like that because I would have to remember to add a trigger for a new device each time I added one.
Thanks,
John
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: February 07 2007 at 21:28 | IP Logged
|
|
|
John,
Currently, that is the way that PowerHome handles triggers. If you wanted to fire a trigger for each device that may change, then you would have to create a trigger for each device. By defining a trigger of [Any], PowerHome would fire that trigger whenever any device had a change. If multiple devices were affected, then the trigger would still only fire one time.
I think I understand what you're looking for though, where the [Any] trigger would be called multiple times, once for each affected device. I'll look into this and see if it's something that I can add without having to rewrite the trigger methodology.
Dave.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: February 07 2007 at 21:48 | IP Logged
|
|
|
Dave,
You wrote: "I think I understand what you're looking for though, where the [Any] trigger would be called multiple times, once for each affected device. I'll look into this and see if it's something that I can add without having to rewrite the trigger methodology."
That's exactly what I am looking for.
Thanks,
John
|
| Back to Top |
|
| |
cmhardwick
Senior Member
Joined: July 08 2006
Location: United States
Online Status: Offline
Posts: 290
|
| Posted: February 14 2007 at 13:37 | IP Logged
|
|
|
I think this trigger (whether needing one pointing to each device or one "any device") will be just what I need to ease integration with XLobby. I could easily do one trigger per device, and configure the formula to basically see what the change actually was and send the appropriate command to XLobby to update the screens there. Can't wait! (and MANY MANY thanks to MannyMan on XLobby (Manny here) for pointing me in the right direction for this integration) 
A question on using the modified current trigger (which has the temp variables for current/previous status). how long would we have to process the trigger items before they were wiped out, in case of a group broadcast scene? This could get hairy with a large scene, such as a sunset scene changing several lights.
Edited by cmhardwick - February 14 2007 at 16:27
__________________
Cicero, Enjoying automation!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: February 15 2007 at 12:52 | IP Logged
|
|
|
Cicero,
When the trigger fires, the TEMP variables will be loaded with the relevant data (including current and previous status) and passed to the called action (a macro or formula). Within this formula, the TEMP (and LOCAL) variables are static even if another trigger comes in or anything else that would seemingly wipe the values. Basically, every "execution event" gets it's own copy of the variables that are unique and unaffected by another "execution events" variables.
Even if the macro "Waits" (goes into suspense and allows other "execution events" to run), that macros variables are stored and later restored when the macro runs again. Of course the GLOBAL system variables (and standard global variables, etc.) can change, but the LOCAL and TEMP variables will be the same.
HTH,
Dave.
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Feature Requests
Topic: Insteon Database Status/Level Trigger
