
LeeG
Members-
Posts
12943 -
Joined
-
Last visited
Everything posted by LeeG
-
The maximum temperature a 2441TH/2441ZTH could report (if it could) is 127.5 degrees. The temperature is reported in a 1 byte field as temp * 0.5. The maximum value in 1 byte field is 255 (255 * 0.5 = 127.5). That is well past the published operating temperature range for 2441TH/2441ZTH of 39°to 104°F (4°to 40°C) and far short of the temperature ranges this topic is discussing. The following is part of the Insteon traffic generated from a Query of a 2441TH. The temperature value returned is hex A6 decimal 166. 166 * 0.5 equals 83 degrees which is the current temp displayed on the thermostat. It is not physically possible for the Insteon message to contain the temperatures being discussed in this topic. Sat 06/22/2013 09:28:39 AM : [iNST-TX-I1 ] 02 62 1D 6C D6 0F 6A 00 Sat 06/22/2013 09:28:39 AM : [iNST-ACK ] 02 62 1D.6C.D6 0F 6A 00 06 (00) Sat 06/22/2013 09:28:40 AM : [iNST-SRX ] 02 50 1D.6C.D6 22.80.0B 2B 6A A6 (A6) Sat 06/22/2013 09:28:40 AM : [std-Direct Ack] 1D.6C.D6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 06/22/2013 09:28:40 AM : [ 1D 6C D6 1] ST 166
-
Remember these are home thermostats. The 2441TH/2441ZTH have an operating spec of 39°to 104°F (4°to 40°C).
-
Look at the simple things first. Look at the Status displayed in the Current State column of one of the other devices that is not working. When the device is turned On does the Current State column indicate On and remain On? Watch the Programs | Summary page for the posted Program. Does it show a Last Run Time when the device is turned On with a Status of True? Does the Status then change to False? For this particular Program is the Save Needed indicator on for the Program Icon?
-
Put the device into linking mode. Right click the primary node and select Write Updates to Device. The ISY has something pending that should be cleared with the Write Updates to Device
-
The Auto DR Scene cannot be deleted and should not be deleted.
-
Chasewood When the Admin Console on one system shows state changes and another system does not that usually indicates the AV on the one not showing state changes is likely blocking the push of data from the ISY to the Admin Console application.
-
Run Tools | Diagnostics | Event Viewer at Level 3. The Admin Console uses the same subscription. Devices that respond to Scene On/Off DO NOT report state changes. The ISY looks at what the Scene action should accomplish and marks the device accordingly assuming the device reacted correctly. See the following Event Viewer trace activity. The first Scene On turned the device On and produced a trace entry that reflects what ISY assumes the device did. The second Scene On has no device state message because the device was already On, therefore no state change. Regardless of whether a state change, note that there is no device response to the Scene On in either case. Wed 06/19/2013 12:39:33 PM : [iNST-TX-I1 ] 02 62 00 00 32 CF 11 00 Wed 06/19/2013 12:39:33 PM : [iNST-ACK ] 02 62 00.00.32 CF 11 00 06 LTONRR (00) Wed 06/19/2013 12:39:33 PM : [ 15 B2 6A 1] ST 255 Wed 06/19/2013 12:39:40 PM : [iNST-TX-I1 ] 02 62 00 00 32 CF 11 00 Wed 06/19/2013 12:39:40 PM : [iNST-ACK ] 02 62 00.00.32 CF 11 00 06 LTONRR (00)
-
If the Thermostat is not displaying the ambient temp that is a thermostat issue. Applications do not control the displayed temp on the thermostat. Contact Smarthome tech support. Sounds like you need a new thermostat.
-
“the screen shows the room temp is 79-80. Why is this? How can I fix it?†The temperature change messages are not making it from the thermostat to the PLM. A few days ago a user was told by Smarthome tech support the thermostat antenna is directional. He placed a Dual Band device across from the thermostat and it cured the communications problems. This is the link to that post viewtopic.php?f=28&t=11656&p=89949&hilit=directional#p89949
-
I am as confused as oberkc as I thought the problem being tracked was the device turning On/Off at times not expected. I added some annotation to the Log that was posted. Outside Front was turned On/Off with activity outside of the 'Program'. It was controlled by the paddle. It was controlled either with the Admin Console or an App. Did the device turn On or Off at times not noted in the posted Log? Outside Front Off 0 Sat 2013/06/15 01:00:00 Program Log - Program initiated Off as expected Outside Front Status 0% Sat 2013/06/15 01:00:00 System Log Outside Front Status 100% Sat 2013/06/15 16:37:09 System Log - device turned On at paddle Outside Front Fast Off Sat 2013/06/15 16:37:46 Web Log - device turned Off using Admin Console or App Outside Front Status 0% Sat 2013/06/15 16:37:46 System Log Outside Front Off Sat 2013/06/15 16:37:47 Web Log Outside Front On 255 Sat 2013/06/15 21:20:50 Program Log - Program initiated On as expected Outside Front Status 100% Sat 2013/06/15 21:20:51 System Log Outside Front On 53 Sat 2013/06/15 22:20:50 Program Log - Program initiated 21% On as expected Outside Front Status 21% Sat 2013/06/15 22:20:51 System Log Outside Front Off 0 Sun 2013/06/16 01:00:00 Program Log - Program initiated Off as expected Outside Front Status 0% Sun 2013/06/16 01:00:00 System Log Outside Front On Level 100% Sun 2013/06/16 14:19:42 System Log - device turned On by paddle Outside Front Ramp Rate 0.5 Sec Sun 2013/06/16 14:19:42 System Log Outside Front Status 100% Sun 2013/06/16 14:19:42 System Log Outside Front On Level 100% Sun 2013/06/16 14:19:42 System Log Outside Front Ramp Rate 0.5 Sec Sun 2013/06/16 14:19:42 System Log Outside Front On 229 Sun 2013/06/16 14:21:26 Web Log - device turned 90% On with Admin Console or App Outside Front Status 90% Sun 2013/06/16 14:21:27 System Log Outside Front Off Sun 2013/06/16 14:21:28 Web Log - device turned Off with Admin Console or App Outside Front Status 0% Sun 2013/06/16 14:21:28 System Log Outside Front Off Sun 2013/06/16 14:21:34 Web Log Outside Front On 255 Sun 2013/06/16 21:21:12 Program Log - Program initiated On as expected Outside Front Status 100% Sun 2013/06/16 21:21:12 System Log Outside Front On 53 Sun 2013/06/16 22:21:13 Program Log - Program initiated 21% as expected Outside Front Status 21% Sun 2013/06/16 22:21:14 System Log The failure to turn Off at 1 AM could be a comm issue, a device issue. Does the ISY Log show the 1 AM activity to turn the device Off?
-
The learned IR codes reside in the IRLinc. Unless that device is reset I don't know why they would go away unless you are talking about starting over. In which case I do believe they would be gone. What problem is happening during the Restore Modem (PLM) that would force a start from scratch?
-
The program is currently changing the Scene Responder On Levels which affect what happens when the Scene is executed by the Admin Console or a Program. More Adjust Scene statements are needed to change the Local values which are what is used when the local paddle is used. The individual devices Kitchen Lights 1 and Kitchen Lights 2 must be Controllers in a Scene. When the device node name is specified in both the In Scene and Set parameters of the Adjust Scene statements the Local On Level (in this case) is set. if From 8:00 pm For 7 hours Then In Scene 'Kitchen Lights' Set 'Kitchen Lights 1' 50% (on level) In Scene 'Kitchen Lights' Set 'Kitchen Lights 2' 50% (on level) In Scene 'Kitchen Lights 1' Set 'Kitchen Lights 1' 50% (on level) In Scene 'Kitchen Lights 2' Set 'Kitchen Lights 2' 50% (on level) else In Scene 'Kitchen Lights' Set 'Kitchen Lights 1' 100% (on level) In Scene 'Kitchen Lights' Set 'Kitchen Lights 2' 100% (on level) In Scene 'Kitchen Lights 1' Set 'Kitchen Lights 1' 100% (on level) In Scene 'Kitchen Lights 2' Set 'Kitchen Lights 2' 100% (on level)
-
These entries are too similar in time on Sat and Sun to be random events. What is in the Programs that are triggered at these times Sat 21:20:50, then Sat 22:20:50 one hour later. Followed by Sun 21:21:12, then Sun 22:21:13 one hour later? Could be a Program that is triggered, performs an Action, Waits 1 hour, performs another Action. Outside Front On 255 Sat 2013/06/15 21:20:50 Program Log Outside Front On 53 Sat 2013/06/15 22:20:50 Program Log Outside Front On 255 Sun 2013/06/16 21:21:12 Program Log Outside Front On 53 Sun 2013/06/16 22:21:13 Program Log
-
The procedure for replacing a PLM is to remove power from old PLM and ISY. Connect new PLM to ISY and plug in the new PLM, then power the ISY. Do a File | Restore Modem (PLM) which will rebuild the new PLM as well as changing every link in every device that has references to old PLM, changing to the new PLM address. See this link to the UDI Wiki for the Replace Modem (PLM) procedure. http://wiki.universal-devices.com/index ... :File_Menu
-
It sounds like the PLM is failing. Right click on one of the nodes that has the green arrow, select Write Updates to Device. If the PLM is intermittent the Update may work. If the PLM has failed the Update would not work. Could also be something new has been plugged into the PLM circuit, a new UPS, computer, cell phone chargers can completely wipe out Insteon communication.
-
Here is link where UDI discusses v.41 KPL viewtopic.php?f=27&t=11560&p=88710&hilit=v41#p88710
-
bredmond I think what you are missing is that each Controller of the Scene has a unique set of Responder values. You are posting the Scene definition when the Scene name is clicked which is the PLM as the Controller. That is, when the Scene is invoked from the Admin Console it works as you intend. For the Fan - High (Scene) click on the KeypadLinc button node name below the Scene name. This is the KeypadLinc button for Fan High. You will find a unique set of Responder values for when the Controller is the KeypadLinc button. Since all the other buttons turn On the other buttons do not have the 0% On Level. Each KeypadLinc button node name in each of the other Scenes will also have to be adjusted. For those Scene the Fan Motor speed will also have to be set to the appropriate speed for the Scene. The key is that in Insteon each Controller (PLM is one controller, KeypadLinc button is another Controller) has a unique set of Responder values. The only rub could be a KPL with v.41 firmware. ISY 4.0.5 works with this level KPL firmware but the KPL has to be added under 4.0.5. EDIT: sorry, I have posted much of what apostolakisl added with his edit.
-
The LEDs are not an issue for ToggleLincs since they only have one LED. Also to be clear, a ToggleLinc can be linked to a SwitchLinc which can be linked to a KeypadLinc. Not only does Relay versus Dimmer not matter as far as linking, the devices do not have to be in the same family of devices.
-
Insteon does not require all the devices to be the same type. Relay type devices are perfectly fine to be cross-linked with a dimmer. The only situation using a Relay SwitchLinc is they only have LEDs for Off and full On so the LEDs cannot show a load at a lower On Level. Other than that Relay devices can ramp a dimmer load up or down just like a dimmer.
-
What level ISY firmware are you using? The device is being commanded by a Program(s) at times other than what you indicated Outside Front Off 0 Sat 2013/06/15 01:00:00 Program Log Outside Front Status 0% Sat 2013/06/15 01:00:00 System Log Outside Front Status 100% Sat 2013/06/15 16:37:09 System Log Outside Front Fast Off Sat 2013/06/15 16:37:46 Web Log Outside Front Status 0% Sat 2013/06/15 16:37:46 System Log Outside Front Off Sat 2013/06/15 16:37:47 Web Log Outside Front On 255 Sat 2013/06/15 21:20:50 Program Log Outside Front Status 100% Sat 2013/06/15 21:20:51 System Log Outside Front On 53 Sat 2013/06/15 22:20:50 Program Log Outside Front Status 21% Sat 2013/06/15 22:20:51 System Log Outside Front Off 0 Sun 2013/06/16 01:00:00 Program Log Outside Front Status 0% Sun 2013/06/16 01:00:00 System Log Outside Front On Level 100% Sun 2013/06/16 14:19:42 System Log Outside Front Ramp Rate 0.5 Sec Sun 2013/06/16 14:19:42 System Log Outside Front Status 100% Sun 2013/06/16 14:19:42 System Log Outside Front On Level 100% Sun 2013/06/16 14:19:42 System Log Outside Front Ramp Rate 0.5 Sec Sun 2013/06/16 14:19:42 System Log Outside Front On 229 Sun 2013/06/16 14:21:26 Web Log Outside Front Status 90% Sun 2013/06/16 14:21:27 System Log Outside Front Off Sun 2013/06/16 14:21:28 Web Log Outside Front Status 0% Sun 2013/06/16 14:21:28 System Log Outside Front Off Sun 2013/06/16 14:21:34 Web Log Outside Front On 255 Sun 2013/06/16 21:21:12 Program Log Outside Front Status 100% Sun 2013/06/16 21:21:12 System Log Outside Front On 53 Sun 2013/06/16 22:21:13 Program Log Outside Front Status 21% Sun 2013/06/16 22:21:14 System Log
-
The Query response has not been changed. Query has always returned the accurate state of the I/O Linc Sensor. If the Sensor is On (Green LED On) Query indicates the Sensor is On. If the Sensor is Off (Green LED Off) Query indicates the Sensor is Off. This problem arises when the Trigger Reverse option is used in combination with Query. Trigger Reverse reverses the commands the I/O Linc sends when the Sensor changes state. When the Sensor turns On (Green LED On) the I/O Linc sends an Off command. When the Sensor turns Off (Green LED Off) the I/O Linc sends an On command. Trigger Reverse only reverses the commands the I/O Linc sends. Trigger Reverse does not change the Query response. The Query response is an accurate state of the Sensor. Since the ISY issues Query every day at 3 AM a conflict can exist between Trigger Reverse and Query. The best solution is to use a magnetic switch that produces the desired Sensor On/Off state without using Trigger Reverse.
-
You need some parens to get the order of precedence correct If From Sunset To Sunrise (next day) And ( Elk Area 'House' 'Armed State' is Armed Away Or Elk Area 'House' 'Armed State' is Armed Night Instant Or Elk Area 'House' 'Armed State' is Armed Stay ) And Elk Zone 'Garage Ovrhd Dr' 'Physical Status' is Open Then Set '1st Floor Kitchen Bar Lights' 50% Else Set '1st Floor Kitchen Bar Lights' Off
-
Look at the ISY Log (not the event trace) to see if it reflects the errant actions of the device at the time they are occurring. The Log should reflect the device turning On or Off is the ISY is aware of the activity.
-
The first statement in the Then clause changes the value of the variable $Remote_Busy. As soon as the Wait is executed the If is reevaluated because of the change in variable value. The If is now False so the Else is executed. The statement after the Wait is never executed. Split the existing Program into two Programs. The first Program contains the existing If clause, with the Then clause running the second Program. The second Program contains a null If section with the Then statements from the current Program. With this split the reevaluation of the If does not affect the second Program
-
Web Sat 06/15/2013 01:33:01 PM : [iNST-TX-I1 ] 02 62 00 00 2E CF 11 00 Read one of my previous posts. The second PLM will not have the link records to support Scene (Group) 2E. The devices will not have the required responder link records for this Scene with the second PLM Insteon address. If using any I2CS devices the second PLM will not be authorized to control the I2CS devices. The ISY CANNOT directly control a Secondary KPL button. It has to be done through a Scene. I you study the hex string you are using to directly control a device you will see that it does not have any field for the Group number that is associated with every KPL button A=3, B=4, C=5, D=6. That is why the ISY CANNOT directly control a Secondary KPL button and why you CANNOT control a Secondary KPL button. With all due respect, without the most basic Insteon details knowledge you are really working in the dark. EDIT: 00.00.00.3 IS NOT the KPL Insteon address. 00.00.03 is the Group number of the button that was pressed. Standard KPL stuff. Every KPL has the same number for the same button. It is not unique to the KPL. There is no place to put that number (00.00.03) in an Insteon direct command. Again, which is why the ISY CANNOT directly control a KPL Secondary button and your second PLM CANNOT directly control a Secondary KPL button. I really suggest you get a developers subscription. We can go through ever detail one at a time this way but you have a hard time believing what is absolute fact, a Secondary KPL button CANNOT be controlled directly by the ISY nor the second PLM. There are many much more subtle details that you will have to take on faith.