| Author |
|
Lenny
Senior Member
Joined: January 06 2008
Online Status: Offline
Posts: 102
|
| Posted: July 05 2014 at 09:32 | IP Logged
|
|
|
First, I'm running PowerHome 2.1.5 with a new 2143s PLM.
Upgrade went smooth. Thanks Dave!
I guess I'm wondering what I'm doing wrong.
I have PLM groups created and can control them in PH and
the respective responders change state in PH &
physically.
When I press one of the physical buttons on a switch that
is part of that PLM group shouldn't PH show that group
state change or do I have to create a trigger to update
the PH group status?
The PLM receives a group broadcast and cleanup,
"powerlinc1 Group: 1, On" but the PH group to which that
switch is a member doesn't update.
I'm trying to keep real world key-presses and PH in sync.
What is everyone else doing to accomplish this? Am I
missing something silly?
Thanks
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 05 2014 at 23:45 | IP Logged
|
|
|
Lenny,
I will need to look into this. PowerHome should update the group status but the problem is it may not update as you expect it.
The dilemma that I have is say you have a group created between 3 devices and the PLM. The way PowerHome is designed to work (I still have to check the code to verify it) is that if ALL 3 devices are on, then the PLM group will show on. So if you manually turn on device 1, the group status won't change. If you also turn on device 2 and device 3, then the group status should also show On. Basically the way its currently setup is that if the status of the devices all match what is expected if the group was triggered from the PLM, then it should show that the Group is On. If any of the devices don't match the settings that the group On would have set, then the group is considered off.
I'll verify the code though to make sure its truly working that way. If the explanation above is not the behaviour expecting, let me know what you're looking for and I'll see if I can make it an option.
Dave.
|
| Back to Top |
|
| |
Lenny
Senior Member
Joined: January 06 2008
Online Status: Offline
Posts: 102
|
| Posted: July 06 2014 at 08:09 | IP Logged
|
|
|
Thanks Dave that helps.
I think I figured out what is happening. I'd be interested if you or anyone can reproduce it.
I have a single switchlinc and appliancelinc Hard Linked and a PLM group with those two devices. Now if I go into device status screen and toggle the group, the group and two devices states update immediately.
If I press the physical switch, both the devices update on device status screen but the group shows OFF. If I just close, device status and re-open it the group shows on like it should.
Same scenario, and I have the web browser open. A "refresh" of the device status page the group and devices shows on. This I expect on the webpage.
So I think I may have been wracking my head messing with links, wondering if my PLM was discarding the packets and there is nothing I'm really doing wrong. I'm curious if others see this.
Here is the links for switchlinc.
106 is the Group in question with the switchlinc and appliancelinc.
The other two are my "ALL-OFF Type" groups. 250 being "upstairs off" and 254 is "all lights". They are irrelevant to this test.
The link I have circled from the switchlinc to the PLM. Is this really required for the PLM & powerhome to "hear" the key press or is the fact the switchlinc is in the PLM DB enough?
Also, should I be clearing the PLM DB and doing an Add Full, Every time I make link or PLM changes?
In Control Center, I query the device with the LOAD on it for state, then always control the group.
Thanks for the response. Much appreciated.
|
| Back to Top |
|
| |
Lenny
Senior Member
Joined: January 06 2008
Online Status: Offline
Posts: 102
|
| Posted: July 06 2014 at 08:49 | IP Logged
|
|
|
Just figured out another one... well at least why its group isn't updating with Keypress. This one is hard to explain.
This one the device is part of my "Midnight Snack" scene PLM group. When turned on it lights dim path to kitchen. The hall light when that group is turned on is at 71%.
What is odd, when that "midnight snack" scene is turned off, PH or the Hall light device seems to remembering the last state of 71%. Then if you physically press either switch at the end of the hall, PH sees it at 71%, even though the light is actually on 100%. I'm sure this is why the "Hall light" 3way switch group in PLM isn't showing on. If I double tap the switch with the load, PH shows 100% and the "Hall light" group turns on.
After I double tap the KPL button to make its "last state" 100%, single presses then show 100% in PH. Even though, it shows 100% the group doesn't update. I still have to double tap the KPL with the local load for PH to show the "Hall light" 3way switch group as on.
If I double tap that KPL with the local load, the group comes on every time. Although this takes closing and reopening device status screen as in previous post.
Thanks again
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2014 at 10:21 | IP Logged
|
|
|
Lenny wrote:
Thanks Dave that helps.
I think I figured out what is happening. I'd be interested if you or anyone can reproduce it.
I have a single switchlinc and appliancelinc Hard Linked and a PLM group with those two devices. Now if I go into device status screen and toggle the group, the group and two devices states update immediately.
... |
|
|
Lenny,
I have been able to reproduce your test scenario and its definitely a problem within PowerHome. Your link setup looks fine. Im tracing the issue now and will include the fix in the next release which won't be long as it'll just be a release to fix the bugs reported so far...no new features.
Awesome bit of debugging by the way. It really helped in pinpointing the issue.
Dave.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2014 at 20:14 | IP Logged
|
|
|
Lenny,
Found and corrected the error with groups updating (your first group problem, I havent had a chance to look at the midnight snack problem yet).
However, while reviewing the code, I have somewhat of a dilemma. When a device is manually switched, it will typically send an Insteon Group broadcast followed by an Insteon Group cleanup. I currently have code that updates the insteongroups table based upon these commands. It depends upon there being a responder link to the PLM from the device and the button matching the group number of the PLM group. Here is my dilemma, the Insteon groups table was primarily designed for when the PLM is sending group commands (links to Insteon devices with the PLM as the controller). Consider this scenario:
A link is created with the PLM as a controller of a switchlinc. The PLM group defined is 2 for arguments sake. If this group is controlled via PowerHome, the status will match the control. If the switchlinc is manually switched (and the PLM receives the incoming Insteon), then the group will also be updated to match (now that Ive fixed it) the manual control being performed. This is all well and good.
Now consider the above scenario but add to it a responder link with switchlinc as the controller and the PLM as a responder (which is what you should do for every device to ensure the greatest chance of the PLM actually seeing manual commands). If you set the button of this link to 2, then the other code that is currently in place (and works) will set the PLM group status to match any physical control at the switch (the controller link doesnt necessarily have to exist either...they're independent).
My problem is Im not sure that this makes sense. The responder link to the PLM really has nothing to do with the PLM controller groups and so Im wondering if this code should be removed. The main reason why Im wondering if this should be removed is because remote links to the PLM can have the button set to any value from 0 to 255. Say we have a totally different switchlinc (from the above scenario) that also has a responder link to the PLM (every remote device that has the ability of physical control should) and its button is set to 2. This new switchlinc also doesnt have ANY controller groups from the PLM. If this switch is manually set, then the PLM group 2 will be updated even though this switch has no PLM group 2 controller group.
Im looking for feedback on what others think concerning this behaviour. It gives the user an option to update a PLM group status remotely (even if the device doing the update isnt a member of the controller group). But Im wondering if this "feature" will cause unnecessary confusion and should be removed.
Let me know,
Dave.
|
| Back to Top |
|
| |
Lenny
Senior Member
Joined: January 06 2008
Online Status: Offline
Posts: 102
|
| Posted: July 07 2014 at 22:06 | IP Logged
|
|
|
I think I follow. I specifically started my PLM groups at
10 just to avoid that confusion myself.
The groups I'm working on in question all control one
load per group. There is just several places that they
can be controlled from, KPL's and SL's. All are hard
linked and cross linked, so they all reflect the correct
state of that one load.
You then build a PLM group with the exact same KPL's and
SL's to control that load from PH.
So the question is what is the best way to keep them both
worlds in sync.
Now, maybe the correct way to handle this is to create
trigger(s) to update only PH PLM group table. In that
case you wouldn't want PH to send any insteon commands as
to avoid multiple trigger fires. Maybe that is already a
PH function and I'm not aware of it.
So in my scenario, I could just monitor the one device
with the actual load, fire a trigger to update the PLM
group table status. The other individual devices in that
are linked together will change through normal links and
PH will see their state change.
One would have to make up their own mind should a group
be status be updated or not. That probably makes more
sense then you trying to predict.
I'd be curious if removing it would have an impact on
anyone else(s) implementation... Chime in or I'd say
toast it and add a function to update the group table
without controlling the group.
Side question: At one point in time you were working on
being able to group triggers, and macros so they weren't
all in one big list. Did that get put on the back burner
or scrapped?
Thanks Dave
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: July 07 2014 at 22:51 | IP Logged
|
|
|
Lenny,
The change Ive made (and will be released shortly once I complete the other reported bugs) should be able to accomplish what you want. Especially since you have very simple groups (the same functionality that you see now in 2.1.5 but without the need of having to close and reopen the Device Status to see the group status change...it'll update automatically).
However, if you wanted to manually update the insteongroups table on incoming Insteon communications, I would use a SQL statement (via the ph_directsql function) to do the update. You would then use the ph_devicerefreshstat function to cause the Device Status screen to refresh.
Not sure if it would affect anyone or not which is why Im leery of just removing the code. No one so far has complained about it being there so I may just leave it in case somebody is using this functionality. I'll continue to think on the various scenarios though and will update on a decision.
Concerning the grouping. Version 2.1.5 has the new labels option. It should accomplish what you're looking for. To make use of it, open the PH Explorer. At the top of the left hand treeview, you'll see a new dropdown showing all labels created thus far. On a new system, you'll see *All* and *No Labels*. To create labels for items, right click the desired item (a trigger, macro, global variable, timed event, etc) and select "Labels" from the popup menu. This will open a window that allows you to create/assign labels to the selected item and show the already assigned labels. The key here is that an item can be assigned multiple labels allowing you to logically group items together. Once you've created and assigned labels to items, you can then filter the PH Explorer to a specific label by using the dropdown above the treeview.
Dave.
|
| Back to Top |
|
| |
Lenny
Senior Member
Joined: January 06 2008
Online Status: Offline
Posts: 102
|
| Posted: July 08 2014 at 07:00 | IP Logged
|
|
|
Thanks Dave. I'm not sure how you have that code written.
If it is in a separate subroutine / function block you
should be able to without much effort check for a flag in
the pwrhome.ini, global variable or sql table if you have
one that would be appropriate. IF value=true or 1
execute.
If not present or false, don't. I'd set it to not execute
by default and if people are using it, then they complain
and you can tell them to create the global variable or
add
a line to the pwrhome.ini. This way you may have a better
idea if it is being used and not have to put it back in
and re-release.
Edited by Lenny - July 08 2014 at 07:01
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PLM Group Behavior
