brockp

So given I put in brand new batteries, and I'm still missing heartbeats do you think the newer/faster PLM would help? Or should I just change my timeout to miss two heartbeats before raising an issue? I just worry not just the false positives about issues, but while I have not missed any 'wet' messages when I test, that those messages will be lost also and defeat the point of having the sensors.

Actually on top of that, I should have kept those batteries, Insteaon claims those batteries should be good for 10 years, https://www.insteon.com/leak-sensor

No the leak sensors all use AA's 1.5V,

Brian, The PLM links Table queried from the ISY is 263 entries, PLM info /status says v85 The PLM label is: 2412S Rev 3.1 0852 As for batteries, they were brand new amazon basics, so no lithium like the original batteries, didn't expect them to last as long (though these sensors are new, but some of them are refurbish so who knows how old the batteries were). I still find it strange how the some of the old sensors have no issues, it's only the newer ones I added. I guess I could compare revision/models Looking in the ISY only a leak sensor with no issues is: 2852-222 v00 One that is having issues shows up the same: 2852-222 v.00 So no luck there. BTW these two sensors are within 10' of each other.

So I swapped new batteries in, and I'm still getting unreliable heartbeats from some of the sensors. I might just increase the timeout to see the heartbeat from 25 hours to 50 so they have a chance to send two heartbeats. Still finding as I add more devices that 4.x with a 994pro is getting less reliable. Eg. I have some programs (that I only use when it's warm so only recently found) look for control signals to then take action. They are not 100% reliable, I do have an old PLM, the one that still provides power over cat5 to the ISY. I see lots of reports of these failing, but mine has not 'failed' Do you think I should replace it if I'm missing signals to my ISY994?

I have 15 leak sensors. I use the programs described here: They were installed in two batches. The first half worked perfectly. The second batch, about 4 of them have very unreliable heartbeats. It's very inconsistent. I have moved them to other locations (many have a dual band device within feet) adding access points close by, and the they still have their heartbeats missed. Generally at least 1 sometimes 2 devices are missed in any given day. The first batch still has no issues. Any thoughts? Can low batteries make the heartbeat weak? Am I running out of hoops? Did I overload my 994pro? Thanks

Ok so starting two days ago the symptoms of not being able to communicate with the 2441th returned, some data would appear, random failures. I went to try today (after three days of waking up to a cold house after weeks of working fine (no changes to network) I deleted the device from the ISY tried re adding this failed several times. Did factory reset twice, still fail. I actually have an older 2441TH that was a referb and different revision that I never used. Connected it, same behavior, I restarted my ISY, my PLM, as well as the two dual band dimmers less than 10 feet from the thermostat all with no change in behavior. I had a few acesspoints and moved them around, to try and make a stronger network in the area of the thermostat, it appears to just stop communicating. My non-referb device is less than a year old, so I'm going to call SH support and provide feedback and try to get it returned.

I should stress after I did my factory reset they have been working much more reliably now, enough that I don't worry. Will see how it works long term.

Yeah DTE Energy and Consumers Energy accepted it though their docs say wifi, I think they just saw 'control it form your phone' and it met the spirit of their intent.

Yeah I got mine on sale and then after a rebate for a 'wifi smart thermostat' from both my gas and power company (AC) I actually paid less than nothing for it. Still though now will seriously look at replacing it with a zWave model. I did try pulling power a few time, deleting re-link, it actually kinda made it worse. Then I found in the manual a factory reset. Given I don't use the schedule in the thermostat at all and use the ISY for all of that it didn't bother me at all do that. This appears to made a world of difference, at least back to how it worked when I first got it. I'll see if this is a recurring behavior or not. I'll go leave a review at SH hopefully people read the reviews first.

Ok so a 'node' doesn't always mean an entry in the ISY like the Main, Head Ctl and Cool Ctl?

The WIKI page covering Thermostats ( https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Linking_a_Thermostat ) States there should be 4 nodes: The main node - this is the main thermostat node Cool Control - indicates when the thermostat is calling for Cool Heat Control- indicates when the thermostat is calling for Heat Fan Control - indicates when the fan is on/off I have deleted and relinked my device a few times and I only ever get 3 nodes Main, cool, and heat. Is this expected and the WIKI needs to be updated? How do I check the current status of the fan on the furnace? The Smarthome manual http://cache-m2.smarthome.com/manuals/2732-xx2-en.pdf Has the following: Group 1-Cooling mode change (scene control) Group 2-Heating mode change (scene control) Group 3-Dehumidifiation, high humidity setpoint (scene control) Group 4-Humidification, low humidity setpoint (scene control) Group EF - Broadcast on any change (notification group for linked software controllers) I don't think groups match up with Nodes in ISY, but it is interesting, and would be curious to know how things match up. Thanks

I have had this thermostat now for over 6 months, and communicating with it or doing anything with it is highly unreliable. I read around and it looks like these devices are probably the weakest point in the Insteon Lineup. I have a 994i/zw Pro. The thermostat is no less than 5 feet away from 2 dual band devices that have no problems, and 15' from an additional 2 dual band devices. The issue is that the ISY does not reliably program and control the device. Often I get "Failed to communicate" messages. It often if I try to query it manually will not show the current set point. In MobiLinc the thermostat shows up blank and uncontrollable. I have tried removing it and re-linking, when I do this the ISY UI shows that it needs to write updates to the device. When I try to write updates I get every time the following: Sat 12/10/2016 12:30:58 PM : [32 F9 67 1 ] Memory : Write dbAddr=0x5001 [00] cmd1=0x2E cmd2=0x00 - Failed Sat 12/10/2016 12:30:58 PM : [D2D EVENT ] Event [32 F9 67 1] [ERR] [1] uom=0 prec=-1 Sat 12/10/2016 12:30:58 PM : [ 32 F9 67 1] ERR 1 I have attached the entire log file from "Write updates to device" I know this looks like just a communication / signal problem, but I really don't see how I can get any stronger RF signal to the thermostat. All the other devices around have no problem (they do have power line though) but are again only a few feet away. This has been the most frustrating thing. Some times I'm not sure the ISY is even doing what I expect it to. For example if I run Query there will be often no error message but there will also not be Current State, no control in MobiLinc etc. I'm ready to toss the damn thing for a ZWave thermostat, is this one just defective? ISY-Events-Log.v4.5.4__Sat 2016.12.10 12.32.20 PM.txt

Chris, Thanks for your reply. The Z-Wave menu isn't what I mean, I men in ISY programs, if I select the device, the only options I am given are lock, unlock, and query. I want to script this up, and not resort to hacking the REST interface.

Is there expected in version 5 to expose other feature rather than lock/unlock/querry in the normal programing interface? Going via rest via network module feels like your expecting a lot of the average user. Eg. I want to add and remove user codes for a given time period for a cleaning service. And I'm hacking around rest from my Linux box.

I have a program that runs to check the status of some sensors (mostly, are doors and garage closed etc). If it fails I want it to notify me, now I can do a text message but I would prefer to have some lights flash up and down to notify me before I go to sleep. The issue is the light that flashes, I can't find a way to return to it's prior state, on or off. In normal programing I would store the state value / struct run my flashing program and then restore the stored values. Is there a way todo this? I am on the current stable firmware. Thank you,

I would like to use bitmasks in my programs. I the idea being that each 'bit' represents some state of a system. I found that I can do bit math when setting a variable, but I want to use that in conditionals. I want todo this so that a variable for an item such as 'garage lights' can remember all the programs that should still be true. Example I want to have them on between some given time period, but I also want to control them when my opener is operated. I don't want the opener timeout to shut off the outside if the other program is still in effect. Each bit would represent this sort of, 'don't forget you should still be doing this other code path while this one finished'. Any thoughts how todo this? It doesn't look like you can do variable math in the conditional at all. Thanks

LeeG, I had Status, not Control, I didn't even notice the difference, looking at the posted programs over and over. I expect this to work, thanks, I'll have to look into it.

I have implemented this program, if I test the sensors by shorting the contacts for 5 seconds, I get notifications, I have older models so they correctly clear back to dry when no longer wet and I see all these updates. The problem I have is heartbeats. Some of my sensors are not in locations I frequent (which is why I have them). If I look in my ISY I see Heartbeat for all sensors marked on, but they all end up in state 2 (heartbeat missed). If I look in the log I see exactly one heartbeat entry per device after a reboot of the ISY, then a second never shows. I have 6 sensors deployed, and the first heartbeat is never missed. Thoughts? Does it get ignored because the Heartbeat value never clears? I would really like to know if a battery has died or what. Thanks!