| Author |
|
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 04 2007 at 21:52 | IP Logged
|
|
|
When an Insteon SwitchLinc is turned off from the SwitchLinc, its database entry shows a Status of 1 and a Level of 0.
But when an Insteon SwitchLinc is turned off from a KeypadLinc button or a PowerLinc group, the Status changes to 1 but the Level does not change.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 05 2007 at 17:35 | IP Logged
|
|
|
Also, the database does not get updated when a SwitchLinc V2 Relay is turned on locally, but it is updated when the relay is turned off locally.
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: January 14 2007 at 10:00 | IP Logged
|
|
|
I'm having a status problem with a PowerHome with a basement light. When the light is turned on at the switch, I see the event come in: "Incoming Insteon received on Insteon DM controller PLC. From Address:[06.FA.95] To Address:[00.00.01] Flags:[207] Cmd1:[17] Cmd2:[0]. Decode: Group Broadcast. From: BASEMENT LIGHTS Group: 1, On", but the status on the Device Status doesn't change and a macro that I have that checks the status of this light before it does something else is failing.
I have created a trigger for the "BASEMENT LIGHTS Group: 1, On" and that does an INSTEON "BASEMENT LIGHTS" ON 255 and that is now causing the status to change.
As far as I know, this is the only light that Powerhome is having status problems with.
Version 1.03.4.9
Edited by Viper - January 14 2007 at 10:02
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: January 15 2007 at 09:04 | IP Logged
|
|
|
I discovered another light/Switchlinc Relay that PowerHome is treating the same way. So again I created a macro that trigger to direct control the light when PowerHome doesn't update the status correctly. When the status is correct, the macro doesn't try to control the light. I don't believe the updates to the statuses of these two devices are failing 100% of the time, but I'll watch it.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 17 2007 at 22:41 | IP Logged
|
|
|
During CES, I encountered the problem where SwitchLinc Relays controlled at the switch are not properly updating PowerHome status. I will be fixing this for the next version.
Viper, if the switch you referring to is a Relay type switch then this is a confirmed bug that I will fix shortly. If the switch is a dimmer type switch, let me know and I'll try to determine what is wrong.
Thanks for catching this guys,
Dave.
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: January 17 2007 at 22:55 | IP Logged
|
|
|
Dave,
Tonight, I just figured out it was every SwitchLinc Relay, and it is totally consistent. So you are correct, the problem is SwitchLinc Relays. I now have a macro I trigger on every SwitchLinc On to cause PowerHome to update it's status.
Thanks for the confirmation!
Tom
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 18 2007 at 00:07 | IP Logged
|
|
|
Viper,
Thanks for the update. Ive been working on this for the next beta and have what should be a temporary fix.
Open the PowerHome Multi-Editor and switch to SQL mode by pressing Shift-F5. Then run the following SQL statement for each Relay type device you wish to fix:
update insteondevices set locallevel = 255,dlocallevel = 255 where id = 'YOURRELAYDEVICEID';
This should get you going where you don't have to create the extra triggers.
Dave.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 18 2007 at 00:44 | IP Logged
|
|
|
Hi Dave,
Thanks for the updates. Will the problem I reported in the first post -
"When an Insteon SwitchLinc is turned off from the SwitchLinc, its database entry shows a Status of 1 and a Level of 0."
"But when an Insteon SwitchLinc is turned off from a KeypadLinc button or a PowerLinc group, the Status changes to 1 but the Level does not change."
be corrected as a part of the change you made in response to the "Insteon Status - On/Off/Dimmed" thread?
John
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: January 18 2007 at 07:42 | IP Logged
|
|
|
Dave,
Excellent! Thanks for the fix! It works nicely.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 20 2007 at 23:47 | IP Logged
|
|
|
John,
Ive been thinking this through for a couple of days and for the most part yes, but not always. I thought I was completely good to go, but after going through everything again, I can foresee a problem.
I originally fixed the problem where dimming to 0 still showed a status of 2 (On). I corrected this so that when the level hits 0, the status will change to 1 (Off).
Here comes the problem. Normally when a SwitchLinc (or other device) is either dimmed to 0 or switched off via the PLC or another devices group command, I should set the level to 0 (I'll be confirming this shortly). There is one situation where this currently does not happen however. On devices where "Resume Dim" is turned on, the level "stays" at the last level and the status is just set to 1 (Off). The Level field is essentially storing what is the "Resume Level". The flag for whether a device in "Resume Dim" mode or not is the "LocalLevel" field is set to 0. After reviewing what Im doing, it's probably not the best design, but Im trying to figure the best way to fix it so Im going to solicit some suggestions from others.
First a little background on the columns were dealing with:
The "Status" field holds the current status of the switch and contains values 0, 1, and 2 for Unknown, Off, and On respectively.
The "Level" field holds the current level of the switch and will contain the level is the status is 2. If the status is 1, then this field should be 0. Currently non-dimmable devices will always have the level as 0 but will be changed in the next version to have 255 when on and 0 when off. Switches in "Resume Dim" mode do not have the level set to 0 when off and instead store the resume level.
The "LocalLevel" field contains the Local On level as stored in the switches internal memory and is read by PowerHome. The field is "copied" to the Level field when a switch is turned on locally if it is not in Resume Dim mode.
The "DLocalLevel" field contains the "Desired" Local On Level and is set by the user. When PowerHome see's a difference between the DLocalLevel and LocalLevel (and assuming that the Write Local Level option is enabled), PowerHome will write the new local level into the switches internal memory. If this field is set to 0, PowerHome will instead set the switch to be in "Resume Dim" mode.
With the background out of the way, I understand the desire for consistency between status and level and see a couple of ways to fix it. I could adjust the ph_getinsteonlevel and ph_getinsteonstat functions so that if the status is 1, the returned level will always be 0. Consequently, if the level is 0, the status returned will always be 1 regardless of the actual database values.
However, if it's desired that the actual database values always be correct, I'll need to restructure a little bit. It occurs to me that since the change to Insteon Status where dimmed to 0 is now Off, that I really no longer need a separate status field and can actually derive status from the Level field. Level = - 1 is Unknown, Level = 0 is Off, Level > 0 is On. I could then rename the Status field as a "Resume Dim" level for those odd devices that use that feature. Or, I could just keep things as they are and just add a "Resume Dim" field.
Anyways, I want to make PowerHome the best that I can for the casual user as well as the advanced user with programming experience and want to do what makes the most sense.
Any input you provide (or any other who wants to chime in as well) will be appreciated  .
Dave.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 21 2007 at 01:27 | IP Logged
|
|
|
Dave,
Interesting information. I want to be able to use the Level value in the database (either by direct query or via ph_getinsteonlevel) to determine the on/off status of the device and its dim level if not off. I don't want to have to look at the Status also. So I support having Level always 0 when the device is off, 255 if a non-dimmable device is on and equal to the actual level for a dimmable device.
I like your idea of renaming the Status field as a "Resume Dim" level since as you said you do not need it and can derive the ph_getinsteonstat status from the Level field.
John
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: January 21 2007 at 08:49 | IP Logged
|
|
|
Dave,
What would happen to the ph_insteonstat function if you changed the status field to be the resume dim level? If you keep the function, but derive the results from the level field, I think that is fine. If you remove the function, then there will be a certain amount of breakage by your customers. I can handle the breakage (as long as I know about it), but in the shop I work in, incompatible changes are few and far between because of the customers.
Tom
|
| Back to Top |
|
| |
ginigma
Senior Member
Joined: June 18 2006
Location: United States
Online Status: Offline
Posts: 127
|
| Posted: January 22 2007 at 15:22 | IP Logged
|
|
|
Dave,
I would agree that 0 for off, 255 for on, and the actual dim value works best.
Charles
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: January 22 2007 at 16:09 | IP Logged
|
|
|
John/Charles,
It looks like that is what I'll do then. John, I know you've got a request in as well for a new Insteon trigger that fires ONLY when a change occurs. Ive been thinking on this one as well and there hasnt really been any good way to do this one but if Im going to rework the table structure a little, then I can probably get this one in there as well.
The problem with the trigger ONLY on actual change is that when an incoming Insteon command is received, an appropriate SQL update statement is generated to affect the updates. That's what makes PowerHome so fast. No checking or running down a list of devices to see if it's affected or not, just issue a single SQL statement and let the DB engine do all the heavy lifting. The problem here is that after the SQL statement is executed, the previous value is lost so no way to determine if an individual device was actually changed or not. Now I could rework the code so that the trigger is checked before the update, but that poses other problems that I won't get into.
However, if I rework the database, I should be able to do it. At this point, Im probably going to change the "Level" field to "Resume Level". The "Status" field will still be the actual status, including level and will contain values of - 1 for unknown, 0 for off, 1 thru 254 for dim level, and 255 for full on. I will then add a "Previous Stat" field to the mix. The way this will work is that the SQL statement that updates the InsteonDevices table will also copy over the current Status value to the "Previous Stat" column (since everything about status will now all be contained within the single status field rather than split between status and level). Then the new trigger can be affected by a SQL statement that returns rows with Status <> "Previous Stat". I think this should work out for well for everybody then.
Tom,
No, no...the ph_getinsteonstat and ph_getinsteonlevel functions are here to stay. The only thing that would be changing would be the internal database representation of data. Anybody that is using the functions should see no difference (other than increased consistency). The only problem would be for anybody that are using backend direct database SQL statements to analyze the table data directly. These (advanced users) would have to make some small adaptations .
Dave.
|
| Back to Top |
|
| |
mccljs
Newbie
Joined: January 01 2007
Online Status: Offline
Posts: 16
|
| Posted: January 22 2007 at 17:43 | IP Logged
|
|
|
Dave,
That sounds really good. I posted some additional information to the Insteon Database Status/Level Trigger thread in PowerHome Feature Requests.
John
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Bug Reports
Topic: Database Status/Level Inconsistency
