Lore

Portal appears to have been down for me since about 9:10 PST.

I miss the portal already. No Alexa commands, no UD Mobile notifications, nothing. I almost had to get up to turn on a light when I remembered Mobilinc talks straight to the EISY. Still, what if my arms were full and I needed the lights on?!?!

I just moved from a hardware failed Polisy to an EISY and both my VUE node and Roomba node are getting those same errors. I already had to install the dev. packages for the HUE node which is working fine. I've reinstalled, deleted and reinstalled, rebooted, etc. No luck. I restored from a Polisy backup, but it was current, PG3X, IOX 5.8.4.

The Insteon leak detectors I have latch the wet state. I have to clear the water and quickly tap the little button to send the all clear update.

Any plans on a work around? I'm a C++/Assembly programmer, so my sympathies with Python. My Roombas need light to navigate and it was sort of nice to script it all.

I've been tempted to plug my fridge into an on/off module. From it's perspective, it's just a random power outage that happens during peak rates.

That's a good idea. I still have a smart power strip I bought at Radio Shack 35 years ago to solve a TV/amp problem. I always see it at the bottom of my power strip box, but I hadn't considered it for power savings. I can think of at least two places where smart strips might help to save a few watts. Most of my vampires, however, are tricky to kill without losing something. My Apple TV is also my homekit hub, for example.

I agree completely, however the new SCE rates (averaging over 50 cents a KWh during peak pricing) and us crazy smart home folks change the math a bit. My Insteon switches, for example, cost me more per month on my electricity bill than my pool and spa filters because the Insteon switches draw power 24/7, right through the peak billing hours and I have 125 of them. All my lights are modern high lumen per watt LEDs and are set to come on dimmed unless I ask for "work lights." My winter average draw right now is 600 watts, 200 watts of fridges, home theaters, lighting, pool filtering, etc, and 400 watts of which are power vampires like Roombas, Alexas, sensors, cameras, alarms, power failure units, GFCI outlets, Insteon switches, and other things that bleed power 24/7. Leaving a 50w bathroom fan on is nearly 10% of my average usage, more if I'm away, and will show up in the bill. My recent tweaking cut 200 watts from my average usage and should save enough to buy an Insteon Module a month, but more importantly, it gets me closer to a practical off-grid system.

I have everything on Insteon switches or modules and have been slowly adding programs to lower my power bill. At sunrise, or if I leave, I turn off any lights left on. My bathroom fans default to 70% which uses half the power and will turn off after 40 minutes if left on. My recirculating pump turns on before I wake up at 60%, which uses less than half the power but still gets the job done. It turns off during peak pricing. I'm looking to add mmWave occupancy sensors as soon as something is supported in PG3. What are other people doing with automation to save power?

Hue alone drops for 1 minute at midnight with the above debug log and two notifications showing disconnect and connect. Hue Hub V2 is hardwired to the same switch as the Polisy and nothing else drops.

I updated to PG3x and am still getting the Hue drop out at midnight. Polisy running 25 Hue Bulbs, 126 Insteon devices, 3 Roombas, 1 Rachio, 2 Venstar, 1 Vue, Weather, and Notifications. PG3x Version 3.2.13 Frontend Version: 3.2.13 IoX Version: 5.7.0

That worked. All connected. Just waiting for SCE to replace my meter for free because it turns out it wasn't HAN ready.

I installed and entered my login. It's showing disconnected. Rebooted, same thing. The log shows the same errors repeated.. 2023-10-04 20:11:23,106 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2023-10-04 20:11:23,107 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db953c7c4_6/vue.py", line 10, in <module> 2023-10-04 20:11:23,108 MainThread udi_interface ERROR udi_interface:write: import pyemvue 2023-10-04 20:11:23,109 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db953c7c4_6/pyemvue/__init__.py", line 2, in <module> 2023-10-04 20:11:23,110 MainThread udi_interface ERROR udi_interface:write: from pyemvue.pyemvue import PyEmVue 2023-10-04 20:11:23,110 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/000db953c7c4_6/pyemvue/pyemvue.py", line 8, in <module> 2023-10-04 20:11:23,112 MainThread udi_interface ERROR udi_interface:write: import boto3 2023-10-04 20:11:23,112 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2023-10-04 20:11:23,113 MainThread udi_interface ERROR udi_interface:write: : 2023-10-04 20:11:23,114 MainThread udi_interface ERROR udi_interface:write: No module named 'boto3'

Same here. Got the email, tried to upgrade, 5 beeps, no change to the version. I assume the entire Polisy update is disabled, IOX 13.2 and ISY 5.7.0, and I'll just have to wait.

I have a Polisy. PG3 Version 3.1.23 Status: Connected Frontend Version: 3.1.23 IoX Version: 5.6.3 Connected No PG3x. I only have what comes down from updating on the ISY screen. Everything has IP reservations and I configured the node with the Hue Hub static IP. The recovery is quick and complete. I have 25 bulbs on my Hue Hub V2, so maybe a longer list causes a brief delay and the time out detection is too short? The Hue Hub really needs a refresh.

Nope. Plus the other nodes stay up, like my thermostat, which will report a drop if I reboot. I suppose the router could do a quick drop at midnight for some reason and it's too quick to be caught by the other nodes. It's not a big deal, it's just that an update to UD Mobile now tells me about such drops.

2023-07-26 00:00:04,272 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message longPoll 2023-07-26 00:01:04,761 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING longPoll 2023-07-26 00:01:04,762 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2023-07-26 00:01:04,765 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2023-07-26 00:01:04,766 MQTT udi_interface.interface INFO interface:_disconnect: MQTT Unexpected disconnection. Trying to reconnect in 10 seconds. rc: 7 This is the log. Seems to show some sort of polling, then a disconnect. It's the same every night.

The node goes offline and comes back at 12am exactly every day. Is this an intentional kludge or some clock timer bug?

You called it. I had a camera powered by the USB power adapter it came with next to a few 2635 On/Off modules. Filtering the power adapter OR replacing the On/Off modules with Revision 1.5 or greater fixed the spurious signal issue. In a modern home filled with automated seasonal effects and smart sensors, it's nearly impossible to have every power adapter filtered, but I've made a solid attempt and have also committed to only using newer modules near where such things are plugged in. As a side note, Insteon has the filters back in stock.

ISY log shows nothing, but I have a few modules randomly popping on, and a few other unreliable modules that sometimes miss their scene messages. I have about 100 modules and dozens of filterlincs on anything that might cause noise. A bit of research shows that Insteon added a checksum in 2012 and about half my modules were older than that. I started swapping out the older modules from my spares and the issues started reducing and the system started getting more and more reliable. Is there a way to get the ISY/Polisy to show revisions? I can only see the hardware version and the address. Also, is there a list somewhere of what was fixed in each revision?

Most of my scenes have no controller and are fired off by programs. The control button is in an empty scene and a program checks status. If it's on, I set stuff how I want then I turn it off. In a few rare cases, I set the scene button to off if anything it controls is tampered with. This allows me to get quickly back to the scene without having to toggle it off and on again. I also try to make sure the switches are set to match the lights they control when I trip off a scene. I sort of had to do it this way once I started mixing in Hue lights and other non-Insteon devices into scenes.

A ton of Matter products and support is/was scheduled for Q1 2023. So far, not even the Hue Hub has been updated and the quarter only has 10 days left. What's the Matter with them?

To clarify, I'm currently using a kludgy set of programs to respond to half a dozen dim ranges from the insteon switch and then setting the hue light to a brightness that matches the switch. This lets guests use the hue lights as if they were normal lights on a dimmer switch. However, other programs, including Hue Sync, can set the lights to various colors and animations as required, making them rather covert party lights while also letting me keep the consistent look of Insteon switches everywhere. I'm looking for a less kludgy way to have a hue bulb follow the brightness on an Insteon dimmer switch.

@GeddyYeah, the I/O Linc sensor status is always correct after a query, but act of doing a query seems to trip the relay when it's in reverse trigger mode. I have no idea why. Also, doing a query changes the status which trips my programs, so I'd have to also delay my programs until after I did the query. I finally gave up and stopped using Reverse Trigger. I use an I/O linc to monitor things like my alarm siren, which is normally open. Programs like MobiLinc assume the I/O link sensor is attached to something normally closed all their icons, include their siren icon, are set up normally closed. That's mostly why I wanted to reverse it. In any event, they work flawlessly if used without Reverse Trigger.

@Geddy @DennisC Thanks. While Query does bring the I/O Linc Sensor to the correct reversed state after a power cycle, the relay sometimes flips during the Query. Not sure if this is an issue with the ISY code or the I/O Linc. I've chosen to stop using the Reverse Trigger feature and simply reversed my ISY logic. This also messes up the display on my MobiLinc Pro phone app a bit, but I was able to kludge around it by relabeling ON and OFF. I suppose I could also build a circuit with resisters and stuff to effectively reverse the trigger as well. It seems the I/O linc preferse normally closed type monitoring.