landolfi

The IOLinc is a spare I switched to about a year ago when I thought the one I had might not be reliable any more (turns out that one just needed to be reset). This spare had never been used in the 5 years I had it and has been working reliably, so I think it is reliable. When this problem occurs I do not see any reports from the light sensor in the eISY log until I force query it, and when I do, it reports On and AC updates. But I suppose if the line is noisy enough the sensor status report would be completely lost and would not appear in the log at all. There were some X10 commands in the log around the time that there might have been an update from the sensor, so I have disabled that program. Maybe that was it all along. Good idea to watch the status light on the light sensor, but I suspect I am going to find it is on but the problem is that the PLM/IOLinc just don't know it. Hence my attempts to force the AC to query the sensor to get it to report its current status. If I were to try to do what my simple program above intends, it sounds like I need to add a repeat to the program, something like every 15 minutes. And to add to the complexity, the light sensor On status update is getting passed on to Home Assistant by the UD Home Assistant integration to inform Home Assistant to turn on some other Zwave lights. So it occurred to me I could use one of my Zwave lux sensor levels in Home Assistant to give the light sensor an assist in case the Zwave sensor knows it's dark but the Insteon light sensor update On from UD hasn't yet been set. That's probably the easiest way to go. Thanks for all the suggestions.

It's a Minotaur light sensor, I think I bought it in the early 2000s. It does have a potentiometer, but it was working at the current setting until recently. I suppose it could become less sensitive as it ages? But it was a bit finicky to adjust and generally (90% of the time) accurately detects when light is needed, which is why I would prefer to leave it as is if possible. The thing is, when the light sensor fails to activate because it turns off when light is already low, as described above, if I query the device it immediately shows On status. As far as I understand, the Light Sensor turns On when light is below the pot value and Off when it exceeds it, but nothing more, there's no lux value. The IOLinc isn't controlling anything directly (nothing is directly connected to it), so as far as I know its function is just to forward the report of light sensor status to the PLM when it receives a report from the light sensor. Could it be something in these IOLinc settings? These settings are the same for both Light Sensor and IOLinc.

I am troubleshooting an old ancient Insteon light sensor connected to an IOLinc that normally reports On when the light level is low enough but it struggles on overcast days. It responds immediately in AC to light changes that are obvious but the problem is that it is reporting Off to AC in marginal light changes but never subsequently reporting On in AC after that even though by then it's completely dark. This usually happens in batches of 4 or more where it goes on/off, then on/off again and Off is the final status when it's completely dark, causing lights not to go on. I'm using it for low light conditions to turn on front room lights when it gets dark regardless of time of day and off when it brightens up again, including the next morning. In thinking about this it makes sense to me that the sensor depends on a certain degree of light level change to report a new status. So my question: Will this program below solve the problem of the light sensor not reporting its status to AC because the light level change isn't large enough? I don't care what happens after 23:15 because it's lights off after 11:30 anyway. And yes, I know I can get a better light sensor for Zwave and I even have some, I just have trouble parting with stuff that still works. Check Light Sensor - [ID 000D][Parent 0001] If From 12:01:00AM To 11:15:00PM (same day) Then Set 'Light Sensor - Sensor' Query

Awhile back as a test I temporarily added a Sengled Zigbee bulb to eISY and later decided to add it to Home Assistant instead, it is now controlled by HA. As a result of adding it to eISY, I now have two devices with a red slashed circle on eISY that I cannot delete. I've tried: 1. Right click device/Remove from Zigbee network (no error, but does not delete) 2. Right click device/Delete ("Request failed", does not delete) 3. Factory reset Zigbee dongle and repeat steps 1 and 2. Same result as above. Any suggestions on how to remove these phantom Zigbee devices? EDIT: Just upgraded to 5.8.4 firmware and the devices are gone.

Thanks! I swapped it for a Zwave plug. I still have one Lamplinc working reliably, and when that goes it will likely be pure Zwave and Zigbee for me with the possible exception of my light sensor/IOLinc combination.

Thanks, I tried that too. Still no luck.

I have an old Lamplinc 2457D2 that may have finally bought the farm. I try to reset it by holding the set button for as long as 30 seconds, but it does not beep, only flashes green until I unplug it. It is otherwise not responding to any Insteon commands. Is there any other way to bring this back?

I have a Yolink temp sensor and it does display in F with the node server. However, the label in the admin console when you view the temp sensor node says Current Temp (C).

UAID and Secret are in the Yoink app under Settings/Account/Advanced Settings/User Access Credentials. That wasn't obvious to me when I first set up the node server.

Within a new automation, using the Entity as a trigger, do you see your state variable as number.xxxx, where xxxx is the state variable name from ISY? You should see both "xxxx" representing Value, and "xxxx Initial Value", representing Init. If you don't see it in the list of Entities under Triggers, you may need to enable the state variable. In some cases I've had to go into the ISY integration and manually enable ISY state variable entities.

I think this means if UAID is reset when password changed, but UAID and secret are the same in the app as they were before the password change, and thus matching the node server config. So it appears changing password has no efffect on node server config, which is great.

Same thing here with the many "Yolink MQTT client disconnected" messages in the HA log. From what I understand, there is an update to HA coming to address this. On HA what I have noticed is all devices update status when the Yolink integration starts, but then no updates until the integration gets reloaded. On eISY, restarting the node server has no effect, it never updates the device status. I'm running PG3x 3.2.17 with IoX 5.8.0.

I haven't checked the eISY in a while since I've moved largely to Home Assistant, but I noticed all my Yolink devices show as "not connected" in the AC even though YolinkSetup says "Connected". The devices do not appear to be updating. I just changed my password but the NS confirg only asks for UAID and secret and those haven't changed, so I don't think it's related to the password change. I know something changed on the Yolink side because the Home Assistant integration for Yolink is broken, could this be the same thing?

I could have sworn that the devices were discovered automatically in the past even though they were idle, but they did eventually show up after each one played audio.

For some reason the free Sonos server no longer works on 3.2.16. Is this a known issue? After installation, the message appears: "No speakers found. Make sure they are powered on and try Disover again." The Sonos app and Home Assistant see the speakers, just not the Sonos node server. I've tried re-installing as well as deleting and re-installing. There are no nodes.