andrewm

Yeah thanks. I thought I'd try here first to avoid burdening Support, but I've now gone ahead and contacted them as you suggested. For those interested in this area, Michel kindly responded that I should use "Emporia Vue, for which there's a node server" The product guide for Emporia is on their website here. I suspect that the node server will have to go out to Emporia to get its data rather than communicate directly with the meter as at present. My preference would always be to do as much locally as possible, rather than be dependent on external services, but it's not a deal breaker.

I've got the 21050 Smart Meter Module installed in my ISY 994 to obtain usage info from my electricity meter. I couldn't find much mention of the equivalent functionality wrt ISY on Polisy. The only smart meter Node Server I saw obtains its data from ISY I did receive a recent email from UDI regarding the Zmatter module which says "Easy migration from 994 500 series" though I don't see the "500 series" label in the UDI store to determine if this is relevant to me. But that email also implied the Zigbee radio isn't yet activated So is there an upgrade path for ISY on Polisy that will still allow continued retrieval of data from my smart meter? If so where do I find the information on doing that? If not is there another approach that people are using? Thanks - Andrew

Just upgraded from 5.0.16c to 5.3.0 and I'm seeing an artifact / error on some of my switches related to the Beep: I don't recall it being there before, but I can't be sure as I don't live in this UI! This particular switch is a 2476D. I didn't check all my devices but I'm seeing it on other 2476D's but not the 2477D. Also some Lamplincs but not others. I assume it's older devices which don't support the Beep functionality; in which case a better indication would be to disable the widgets rather than display gobbledygook.

Thanks for the reply. I was hoping to have some low-voltage I/O capability. Do you or anyone else know if it'll be possible to use plugin USB boards for that, or will we have to have separate external devices, such as Raspberry Pi?

The Polisy product page is very light on hardware specs, and I can't find them in the forums. It does state "3 x 1 GB Ethernet ports", which is a start but then adds "extensive I/O features" which is very vague! So my specific questions would be: - How many USB ports? - Does it have user-accessible GPIO capability? - Does it have relay outputs? If so, what are the electrical specs? - Does it have a cooling fan? Thanks in advance - Andrew

I had a very similar issue to others here which stumped me for a while. I have multiple scenes in the kitchen, one of which is "All kitchen lights". At some point that scene stopped working via Google Home - the lights would turn on then immediately off, or some random combination thereof. But it worked fine via Amazon Echo. I guess Google is trying to be clever by interpreting the world "all" and then controlling all the related "devices" it knows about, which given they are scenes has weird results. The work round is to use synonyms for "all" (entire, complete, everything) but that's effectively whack-a-mole, because Google will eventually work out the synonyms and I'll be back at square one. Google should instead try for a more exact / literal word match against the spoken before trying to add interpretations based on word meanings. So much for Artificial intelligence!

Ha. Maybe AI can fix the damn AllOn problem!

I have the same problem as the OP. It seems like Google decides if any words match and then turns on all the matching devices. I think it does indicate in its confirmation whether it has a unique match (eg "Turning on normal family room lights") vs an approximate match (eg "Turning on 3 lights") - the number in the latter indicating there are multiple matches. Unfortunately, though, there's no way to know which lights (ie devices / scenes / whatever) it's decided to turn on - it'd be nice if the Activity Detail included that, and it'd be nicer still if you could feed back to Google the fact it got it wrong!

I've recently upgraded my ISY 994i with the High Powered Zigbee Smart Grid (SEP1.1) Radio so as to connect to my PG&E smartmeter. I do have connectivity and am receiving meter usage info, but no pricing information. Looking around the forums I found a post that mentioned changing the firmware when the new radio was added. There were no instructions provided with my hardware upgrade, so I hadn't realized this was necessary. However now having changed to the ZS firmware, I'm not seeing any change in functionality - it's not working any better and I'm still not getting pricing information. Our PG&E plan is based on net metering with Time-of-use (TOU). Should I be getting that pricing info from the meter? If so, how do I work out where the problem is? - Andrew

I'm ok now as well - thanks

I had exactly the same thing happen to me today, and I'm currently stuck in the same position as you - unable to add any programs. In my case I believe I'd got up to 12 entries and everything had been working ok. But then I decided I wanted to change the UI to show all entries at once, by changing the number of entries per page from 10 to 25. At that point suddenly I was left with only 2 entries. After restarting the browser / rebooting ISY it didn't sort itself out so I selected the option to delete all entries. I could then re-add scenes, but not programs. Trying to add entries for programs I'd added previously (before the delete all) fails with "Device already has a spoken". Adding an entry for a new device doesn't return any error, but there is no new entry listed - then trying to repeat the operation will fail with "Device already has a spoken".

I agree - it's more memorable and personal (think "Siri" or "Alexa"). Could be worse though - eg "Aye-Ess-Why-9-9-4"!

Thanks Lee, I stand corrected - I hadn't realized it handled more than the credit card remote codes, which in my case are programmed into my universal remote. I agree 511 nodes would be a little much to pre-add to ISY! It would be nice if the IRLinc pre-assigned the 12 nodes for the standard credit card remote in its 2nd database, in which case ISY could optionally pre-populate them when the device is added, But it sounds like that's not the way it works. What a pity - I guess I'll have to do this the long way. - Andrew

Michel, Thanks for the information - I'm glad it's operating as expected. I do find it a bit strange though the way the IrLincRx works in comparison to the RemoteLinc remote control. The IRLincRX has only a finite set of IR codes that its remote transmits - it's not like it learns any old code from any remote. So it is basically similar to the RemoteLinc, in that the device subnoodes are predictable. In fact the IrLincRx has an advantage over the RemoteLinc in that the IR receiver unit is continually connected to the Insteon network, as it's not a battery device. Yet the RemoteLinc subnodes are created when the device is added to ISY, but that's not the case with the IrLincRx where the subnodes are only created in ISY on a button-by-button basis. I presume this is more of an Insteon issue though, rather than an ISY issue? - Andrew

Hi Michel, Well that's good news - or would be if it worked! The first node on my old device is as follows (there are 5 others, because of the buttons I have defined): <node flag="128"> <address>F 5A 50 1</address> <name>FR - Remote A</name> <type>3.6.0.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <pnode>F 5A 50 1</pnode> <ELK_ID>I08</ELK_ID> <property id="ST" value=" " formatted=" " uom="%/on/off"/> </node> The only node on my new device is as follows: <node flag="128"> <address>22 7B 56 0</address> <name>NewIrLinc-22.7B.56.0</name> <type>3.6.64.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <pnode>22 7B 56 0</pnode> <ELK_ID>O12</ELK_ID> <property id="ST" value=" " formatted=" " uom="%/on/off"/> </node> The types are not identical, but I don't know if they are identical enough? I don't get the option to replace my old with my new device. Attempting to restore my old device results in an error as the attached log shows. So if the 2411R is restoreable / replaceable, the fact I can't restore mine and I get an error in the log implies it's probably bad? But then if the reported types are close enough, which can't I do a replace with the new device? - Andrew ISY-Events-Log.v4.2.10__Sun 2014.09.28 02.07.12 PM.txt

Hi Michel, Mine is the 2411R - ie Rx not TX. I take it this has the same problem - ie it cannot be restored either?

It says "v9B" - Andrew

As part of my recovery process after replacing a failed PLM, I have gone through all my devices and compared the link databases with ISY's own tables. This revealed a mismatch in my IRlinc 2411R's link database. Unfortunately I was unable to then restore the IRLinc - I kept on getting failures during the restore process, even after performing a factory reset on the IRlinc. Thinking my IRLinc had gone bad, I purchased a new one and added it to ISY as a new device. But now right-clicking on my old IRLinc doesn't give any option to replace it with the new one. It's been a long time since I added my original IRLinc so I'd not remembered about any special linking procedures. Now looking at the docs makes me wonder if the restore / replace procedures for IRLincs are different? Is it significant that the nodes for the IRLinc are created dynamically - my old factory reset'd IRLinc shows multiple nodes in ISY and the new one only has a single node? Does that screw up the restore / replace? (This is using ISY 4.2.10) - Andrew

ISY is 4.2.10 PLM Sticker says: 2413S, v1.C, 1425

I just had this happen to me as well. In my case all my lights went on, my garage door opened, my ceiling fans went on full blast, and my sprinklers turned on. And being that this was 1am, my wife got pretty pissed! Luckily I was here and still awake when it happened. Reviewing the logs does show a motion event outside the house at the time this happened - this turned on the scene for the garage lights, which includes in the scene a KPL button indicator. Garage / Garage Motion Sensor Status 100% Wed 2014/09/24 12:47:33 AM System Scene:Outside / Sc: Outside Garage Lights On 255 Wed 2014/09/24 12:47:33 AM Program Living Room / LR - Thermostat Status 76 Wed 2014/09/24 12:47:34 AM System Scene:Outside / Sc: Outside Garage Lights On 255 Wed 2014/09/24 12:47:34 AM Program Family Room / FR - Thermostat Thermostat Mode Off Wed 2014/09/24 12:47:35 AM System Family Room / FR - Thermostat Fan Setting Auto Wed 2014/09/24 12:47:35 AM System Garage / Garage Door-Sensor Status 100% Wed 2014/09/24 12:47:35 AM System Scene:Garage / Sc: Garage Door Status On 255 Wed 2014/09/24 12:47:35 AM Program Living Room / LR - Thermostat Thermostat Mode Off Wed 2014/09/24 12:47:38 AM System Living Room / LR - Thermostat Fan Setting Auto Wed 2014/09/24 12:47:38 AM System Scene:Outside / Sc: Outside Front Porch On 255 Wed 2014/09/24 12:47:39 AM Program There are no loops, but it looks like the scene did get initiated twice within a second for some unknown reason. This would appear to be consistent with other reports of this happening. In my case this is the first time it's happened in 7 years of having an ISY, so hopefully it will remain a rare occurence. However I did replace a failed PLM a week ago, and just this last weekend I also replaced the KPL in question, because of difficulty syncing the link database with the ISY; so maybe there is a connection between these changes and the AllOn event? The fact the AllOn event is possible and can't be disabled on a per-device basis, is bad design by Insteon, given the network is not 100% reliable, and potentially very dangerous. The fact the event can occur accidentally casts a pall on Insteon. The really bad thing is I don't see a good way to counteract it - which is not good news when it's performing control operations such as opening doors and turning on sprinklers. The reason being that ISY had no indication that (eg) the sprinklers were turned on, so couldn't trigger a counteracting response - even my watchdogs / guards wouldn't work since all programs are bypassed. I presume the reason ISY had no indication was the network must have been flooded with status messages, though I don't see evidence of that in the log. So my actions will be: Re-program the motion detector processing to guard against a new response when an existing response is in progress. Replace the sprinker control device with one that has momentary-on capability (where momentary = "60 seconds") rather than the on/off state being under control of ISY. Longer ON periods can be handled by an ISY program, but accidental ON's will only result in 60 seconds run-time. Tbh I'd actually been meaning to do this for a while My questions / suggestions are: Can ISY not see these AllOn messages on the network, and create appropriate triggers for them? Eg if I could trigger a program based on an AllOn event, then at least I could initiate an automated recovery procedure. Are any devices more susceptible than others to creating these bad events? Eg newer / older devices? - Andrew

Hi Michel, It is a mismatch, but the other indicators indicate the record is not in use, therefore the mismatch can be ignored. ISY Compare already uses the "Mismatch / Ignore" label for link records in other situations, why wouldn't it here? Or are you suggesting the mismatch should not be ignored?

Xanthros: Thanks for the suggestion. I've found the post you're talking about, so I'll take a look at repairing my PLM Michel: My point is, shouldn't ISY really report "Mismatch / Ignore", if that final record is marked as not in use? The fact it's just marked as "mismatch" could lead people to perform unnecessary (and lengthy) recovery procedures. Thanks - Andrew

(This is on ISY 4.2.8 & 4.2.10) I had a PLM failure last week, which resulted in me spending many hours yesterday trying to make sure all link databases were correct following the installlation of its replacement. When scanning the device link databases for my devices and then comparing them against the ISY's table, I had several which reported mismatch results similar to the attached screenshot. Namely that the final record in the ISY was all zeros and the final record in the device had a first byte of zero, then other non-zero values. ISY Compare states that this is a "mismatch", but shouldn't it be "mismatch/ignore"? Because according to my reading of the Insteon specs, a zero in the first byte indicates the record is not in use and it's also a high-water marker. Ie this condition is OK. Note that when I tried to clear these "mismatches", I did a device restore, but this did not change that final record; ie it was not set to all zeros as in the ISY links table. The only way I could get the devices to match was to reset the device back to factory, then restore it from ISY - something that is time consuming and would be difficult for some of my more inaccessible devices. So I'm hoping that my reading of the specs is correct and I can just ignore the ISY's "mismatch" assesment for these records - Andrew

Based on what you're saying about these being identical I'd actually expect the button group dialog to change based on the scene membership of the KPL buttons. But that's not what I see - all the button grouping dialogs I checked in my system report the same 'basic' configuration - each button has a greyed out mark indicating it's a controller and no other buttons are checked at all as responders. But that's really off topic as it looks like I'm doing things correctly by using scenes. Do you still want me to reset a KPL and log the restore? - Andrew

"Button grouping" is an additional dialog accessed via the Isy admin screen for Keypads. It allows things like mutual exclusivity. I don't use that dialog I do have buttons from the same KPL in the same scene. If these are equivalent I didn't realize. Certainly looking now at a button grouping dialog, there's nothing that suggests to me that things are grouped in any way, but I may be misreading that dialog as I'm unfamiliar with it and I don't find the operation intuitive. Does that clarify?