Lore

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?

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.

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.

When the Polisy (or formerly the ISY) gets rebooted it's out of sync with the sensor state of any I/O module set to Reverse Trigger. I need to query or close/open what's connected to the sensor pins. This effectively makes using the Reverse Trigger mode unreliable after a power failure.

I would like my insteon dimmer switch to control my hue lights. I'm using a Polisy with the latest firmware and the latest PG3 Hue software. Right now my code is a stack of programs for each dim level as shown below, which works albeit with less granularity than ideal. I'd like to just copy the Insteon Dimmer level directly into the Hue brightness and possibly compute the color temperature to mimick a Philips Warm Glow bulb when the bulb is controlled by the switch. Bar Switch Dim66 - [ID 003F][Parent 0001] If 'Bar Down Lights' Status >= 35% And 'Bar Down Lights' Status < 70% Then Set 'Hue / Bar' Color Temperature 2500° K Brightness 128 in 400 ms

That was useful. I guess I should have dug up the original email. I forgot it came with instructions. I even had the antennas wrong. I guess it's just waiting for matter stuff to arrive and the software to update.

I tossed my zmatter board into the middle slot, not sure if that's right. I don't have any zwave devices. I also checked zwave support on the ISY config page.

I have IP reservations for everything, the HUE hub and the Polisy. They're replacing the electrical wires and transformers in my area so I've been suffering a lot of scheduled power outages. I was hoping, after moving to ISY on Polisy HUE would magically work after an outage, but alas, it did not. After a power outage the HUE node is empty so I have to restart it, then I have to scan for nodes on the ISY and my HUE scripts works again. I also have a few Insteon low voltage moduals that are reversed states that must be cycled to get into the right state, making it more work than it should be to fully recover from an outage. For now, I threw on a huge UPS and haven't had time to more completely debug what happens after the power is restored.

I'm having what seems to be the same issue. I was using the original hardware ISY and the Hue V2 node, then I recently upgraded to Polisy ISY and the Hue V3 node. Same before and after the upgrades. The Hue lights can't be controlled by the ISY after a power failure. I can mess with it and get it working again, usually by restarting the V3 Hue node and pulling down the nodes on the ISY.

Oddly, I pull the scene names and numbers from the Hue Rest API. The phone app also pulls the names from the hub, but orders them differently so without the API, I have no idea what I'll get when I set a scene on the Polisy node. I'm working around the lack of support for the "smart" stuff I got at Costco by capturing network traffic to the devices and playing back the command when I get a UDP message from the ISY network resource. I just pre-ordered the Matter board and remounted the Polisy in a high and central location, so I'm hoping things will get a lot easier in the near future. Smart stuff is sort of a mess of proprietary protocals with decent SDKs few and far between, requiring far too much hacking.

No problem, it's great and fast! I have a huge Insteon setup with Insteon switches controlling HUE bulbs and a lot of Network commands going out to custom audio software for announcements and scene sound effects. My biggest issue, after getting around the update bug, was not realizing I needed to install the trial portal to get the portal code to install on the polisy ISY. After that it was just restoring everything and hitting buttons to refresh stuff until things worked. I was using a mix of Network commands to the HUE hub and HUE node commands. While that worked when I was using two boxes with two IPs, that failed on the single Polisy box. I switched to using just the HUE node, which is somewhat lacking, it really needs to show the scene names. I'm up and running and everying is vastly more responsive. My only question now is when will more PG3 nodes show up for all the other smart stuff I have? Things like the Atomi string lights from Costco or the Amazon Air Quality monitor? It seems like I should just be happy everything is working so well and just wait to see if Matter takes over or Insteon recovers.

That seems to be all the information there is right now. Good news though. Hopefully it'll be followed up with more details on when the Insteon products will be back in stock.

I'm a bit worried ISY on Polisy will be some work and won't solve my entire problem, especially if my loss of Hue lights was caused by the Polyglot Hue Node starting up before the Hue Hub was fully booted. What I think I really want is a power up delay for the Polyglot Nodes, so what they talk to has a chance to boot. Maybe just put a long sleep in the startup script or something.

Does that work? I mean both the ISY on Polisy and the ISY starting before the Polyglot?

When my power comes back on, it seems the Policy seems to boot too fast and I get the message ISY994 not found on network. If I reboot the polyglot all is fine. I checked it, because some Hue lights were not responding to ISY commands to the Hue node. Rebooting the polyglot fixed that and the error message. It seems like there should be a retry, or the delay option on the Policy. Or can someone recommend a device to delay power after a power outage?