LeeG Posted February 19, 2013 Posted February 19, 2013 Roman Glad you found the problem. Trigger Reverse is often the cause of problems. Although it is easier than changing out the magnetic switch, Trigger Reverse does not affect the Query result. When the Query is done at 3 AM the Sensor node changes state because Query returns the true state of the I/O Linc Sensor rather than the command reversed state that Trigger Reverse generates. Quote
barryH Posted February 19, 2013 Posted February 19, 2013 so the beta Dual Band KPLs went in smoothly, but now i noticed something odd. in the past a KPL would have a + next to it to expand and contract the buttons below it. so if you wanted to put it in a folder you would highlight the "main" button and add to folder and they would all automatically go into that folder. the 2 new keypads have no+ so you would have to put them into the folder one by one. was that intentional or needs to be fixed? thanks barry Quote
Michel Kohanim Posted February 19, 2013 Author Posted February 19, 2013 Hello io_guy, I do not have any problems here. barryH, this is manual. Please right mouse click and then choose | Group Devices. Bug reports: Fixed: [39]- IOLinc Scene status still not working properly Fixed: [40]- Devices show 100% instead of On With kind regards, Michel Quote
arw01 Posted February 19, 2013 Posted February 19, 2013 so the beta Dual Band KPLs went in smoothly, but now i noticed something odd. in the past a KPL would have a + next to it to expand and contract the buttons below it. so if you wanted to put it in a folder you would highlight the "main" button and add to folder and they would all automatically go into that folder. the 2 new keypads have no+ so you would have to put them into the folder one by one. was that intentional or needs to be fixed? thanks barry What Beta dual band KPL's? Been waiting for dual band KPL's for a while. Quote
barryH Posted February 19, 2013 Posted February 19, 2013 They are in Beta testing now and you will probably see the in a couple of months Quote
andyf0 Posted February 19, 2013 Posted February 19, 2013 Having problem with Venstar thermostats. While mode changes and setpoint changes are correctly reported to ISY the current temperature is not updated in the ISY. If you see the event viewer log below you can see a temperature change message to 74 degrees (4A) but the status shown does not update, still shows 75 degrees. Quote
Xathros Posted February 19, 2013 Posted February 19, 2013 This morning I woke up to the house at 60F. I keep Venstar stat that controls my oil burner set at 60 and have a few programs that watch the temp as reported by the Venstar and turn on/off my pellet stove as necessary. When I logged into the admin console, it reported the temp as 69F. As soon as I hit query, the temp updated to show 60F and the pellet stove came on. After an hour or so, I looked again and the Venstar had come up to 65F but the admin console still showed 60F. The corrected again as soon as I hit query. Testing comms between the console and the Venstar shows consistent 3H/2L when adjusting setpoints via the console. I did a show device links table and compare: Attachment: Extra Record does not sound right to me? My plan is: Query Engine and Restore Device but figured I'd post here first just in case you want my to try something else first. -Xathros Quote
andyf0 Posted February 19, 2013 Posted February 19, 2013 As Xathros pointed out a Query on the thermostat does pull the correct temperature into the ISY. Quote
Xathros Posted February 19, 2013 Posted February 19, 2013 As Xathros pointed out a Query on the thermostat does pull the correct temperature into the ISY. Andy- For now, I have a program query the Venstar every 5 minutes. That should solve the problem till it gets fixed. -Xathros Quote
andyf0 Posted February 19, 2013 Posted February 19, 2013 I only have a couple of programs that check the temperature to account for a missed heat / cool on / off message. I've disabled them until this is fixed. But that is a good idea. Quote
Michel Kohanim Posted February 19, 2013 Author Posted February 19, 2013 Hi Guys, Thank you. Bug ID #44. With kind regards, Michel Quote
Goose66 Posted February 20, 2013 Posted February 20, 2013 Sort of melancholy that the I can no longer look forward to ISY99i updates. So much promise and so much future functionality that never came to pass. I guess it's time to move on to the next HA solution. Quote
LeeG Posted February 20, 2013 Posted February 20, 2013 kingwr Have you seen this offer viewtopic.php?f=44&t=10771 Quote
Goose66 Posted February 20, 2013 Posted February 20, 2013 I see that. What does the 994 offer over the 99i - more processing power? If just FLASH memory is the problem, why can't I just replace the SD card in my current 99i? Quote
LeeG Posted February 20, 2013 Posted February 20, 2013 The SD card size is not the issue. It is used to store the configuration and image data. The ISY has memory that supports its operation. It is this memory that is larger on the 994 in addition to supporting one of two Radios, ZigBee or ZWave. Quote
LeeFleishman Posted February 20, 2013 Posted February 20, 2013 Hi Guys, Thank you. Bug ID #44. With kind regards, Michel I too have found that ambient temperature (as indicated on the face of the T'stat) is not always correct in Admin Console (and by extension, MobiLinc). I've replaced my two original Venstars (for other issues in addition to this), in favor of a couple of the Insteon 2441TH T'stats. This did not resolve the erroneous ambient temperature indications. Steve Lee provided me with the answer during a telephone conversation a few days ago. According to Steve, the 2441TH does NOT send an Insteon message when the ambient temperature changes. It only communicates changes in OPERATING STATUS (e.g. heat or cooling going from on to off, mode changes, etc.). The thinking, during development of the 2441TH, was that if the T'stat sent a message for every change in ambient temperature, it could cause a lot of Insteon traffic -- especially in a commercial or industrial application in which many T'stats are deployed in a large building (such as the project I was recently involved with -- 80 HVAC package units, 80 T'stats, in a very large fitness club). The solution for my two Insteon 2441TH's was to create an ISY program to query both T'stats every 15 minutes. While this may not be appropriate for the large commercial/industrial applications (because it too would cause tremendous Insteon traffic), it seems to be a satisfactory work-around for my simple residential application. I hope this helps. Lee Fleishman INControl Home Automation Thousand Oaks, CA Quote
Michel Kohanim Posted February 20, 2013 Author Posted February 20, 2013 Thank you. This is indeed a bug and has already been fixed in 4.0.2. With kind regards, Michel Quote
LeeFleishman Posted February 20, 2013 Posted February 20, 2013 Michel, I need a little help to understand this. If the T'stat does not in fact send an Insteon message when the ambient temperature changes, how can this be resolved with a firmware change in the ISY? Best, Lee Fleishman Quote
nstein Posted February 20, 2013 Posted February 20, 2013 I am experiencing performance problems after using WOL. After two wol attempts isy is no longer loads my node list before timing out. Steps to reproduce: Test loading rest/nodes (mine normally takes ~5 seconds to load) Trigger wol via rest (or web interface) load rest/nodes, (this time it took ~11 seconds) Trigger wol via rest a second time load rest/nodes (times out) I spent much time trying different firmware versions before narrowing the problem down to WOL; The problem first appears in 3.3.4 and is still in 4.0.1, downgrading to 3.3.3 fixes the problem. Note: I have many devices, ~100, and that normally slows down my node list load times, the effect might not be as noticeable with fewer devices. -Nick Quote
LeeG Posted February 20, 2013 Posted February 20, 2013 LeeFleishman My 2441TH reports temp changes. These are two that were just generated as I held the tstat between my hands to raise the ambient temp. It is reporting in Celsius at the moment which is why the values seem low. The 0x2D is decimal 45 x .5 = 22.5 degrees. The 0x2E is decimal 46 x .5 = 23 degrees Wed 02/20/2013 11:37:03 AM : [iNST-SRX ] 02 50 1D.6C.D6 19.70.06 01 6E 2D (2D) Wed 02/20/2013 11:37:03 AM : [std-Direct ] 1D.6C.D6-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Wed 02/20/2013 11:37:39 AM : [iNST-SRX ] 02 50 1D.6C.D6 19.70.06 01 6E 2E (2E) Wed 02/20/2013 11:37:39 AM : [std-Direct ] 1D.6C.D6-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Quote
andyf0 Posted February 20, 2013 Posted February 20, 2013 Michel, I need a little help to understand this. If the T'stat does not in fact send an Insteon message when the ambient temperature changes, how can this be resolved with a firmware change in the ISY? Best, Lee Fleishman The Venstars I have do send ambient temperature values. The ISY f/w 4.0.1 didn't update it's own internal values with those sent by the thermostat. As Michel stated it is fixed in 4.0.2 which I am anxiously waiting for. Quote
Michel Kohanim Posted February 20, 2013 Author Posted February 20, 2013 Hi Nick, BugID# 51. The thermostat issue is already fixed in 4.0.2. The only issue is that we don't want to have beta releases every week without substantial improvements. We'll see how many bugs we can fix by Friday and then decide whether or not to release 4.0.2 by then. With kind regards, Michel Quote
davidology Posted February 21, 2013 Posted February 21, 2013 I/O Linc Relay slider now sets Responder On Level to 0% or 100% - 4.0.1 change, works great However, regardless of whether On Level at 100% or 0% the I/O Linc Relay Status is reversed. The Relay action is physically reversed with 0% On Level. Scene Off button turns Relay On and Scene On button turns Relay Off as expected. The Relay Current State Status correctly tracks the physical state of the Relay. This is change at 4.0.1 and is working correctly. The problem now is when the Responder On Level is set to 100%, Scene On turns the Relay On as it should, however the Relay Current State Status is still reversed as though the Responder On Level was set to 0% On Level. Scene On turns Relay On correctly, Relay Status shows Off. Scene Off turns Relay Off correctly, Relay Status shows On. Confirmed. Having the same problem: state of IO Linc is reversed in the ISY for the device when a controller of a scene sends an ON or OFF. For example, sending an ON from a controller of a scene closes the contacts of the normally open circuit ("On"), but the ISY will report the status of the IO Linc device as OFF. Sending an OFF from a controller opens the normally open circuit ("Off"), and the device responds accordingly, but the ISY will report the IO Linc device as being ON. Querying the IO Linc reports the correct status. It appears to be isolated to controllers of a scene. Quote
RLIKWARTZ Posted February 21, 2013 Posted February 21, 2013 I use the t'stat to drive a few things so it's kind of important for me. Quote
Xathros Posted February 21, 2013 Posted February 21, 2013 Not having noticed any issues with my garage door IOlincs, I decided to do a little testing this morning to see if I was having the same problems everyone else is reporting with them. So far I don't think I am but I'm not quite done with my tests yet. I did notice something that I think may be wrong and wanted to mention it and see what you all think. Right now the door is closed, Admin console shows sensor is off. This is correct. From the console, I query the sensor, the query returns Off as it should BUT my door closed notify program runs. If Status 'Garage / Garage Door IOLinks / GD- Dad Garage Door Sensor' is Off Then Resource 'NOTIFY - Dad Garage Door Closed' Else - No Actions - (To add one, press 'Action') The status of the sensor did NOT change due to the query yet this program fired. If I query again, the program fires again. Without the status changing. I don't think this program should notify unless the sensor status CHANGES from On to Off. Is this a bug or am I overlooking something? -Xathros Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.