All Activity

I have a really old ring door bell battery in this condition. Takes hours to charge it up, or appears charged enough to work. But it keeps working for a number of months including video recording activities. It's not landfill worthy yet so I keep recharging it, waiting until its a functionality problem or drains in a few weeks. Depending how often the mini remote is used, eg occasionally or more often daily, you try brian's approach, see how long you can get away with using it normally, until the recharging becomes annoying.

v1.7 is an older revision. The date code looks like week 50 of 2014. My 2342-232 (4 scene) is a v2.05 date code 1631 week 31 of 2016. My thoughts are the battery is getting weak and the charging circuit is not seeing the battery voltage high enough to trigger the fully charged sensor. So its always trying to charge the battery. The battery has an over charge & over current circuit so it should not be effected too much. As a test. Try seeing how long the remote works after a few hours charging. To see how long the remote works before needing a refresh charge.

Update: Seems my solution resembles this earlier thread . Thanks to Michel and his prompt response to my ticket, I successfully installed and started eisy-ui by accessing eisy.local via command prompt and following the ssh commands. Thanks

I got this figured out. Thanks again Brian and Paul!!

Thanks Paul and Brian. ok new 2413U in place and everything came back up on the insteon side. now to fight with the 3 schlage locks and zwave. I am not running anything overly complete. is there a way to independently migrate the zwave stuff? I have been poking around and it does not look like it un less i am missing something.

Well sure enough that works (and not at all obvious that those buttons are anything other than labels). I'll admit I do not frequent these forums despite having been a user for over a decade.

Is/was your spoken really “turn off all the lights”? It would appear (to me) Alexa+ thinks it “got smart” and was controlling anything you had in the system as a “light” and turned them off within Alexa(+) rather than the program/scene you have in IoX. I would suggest making the spoken a simple word/phrase. That way Alexa+ knows you want to control something from IoX. I think some have just a “goodnight” scene or program that is run. If you just said, “Alexa, turn on bedtime” and your bedtime spoken ran a program or turned the scene off it would work as you expect. But by using the command “Alexa, turn off all lights” it’s looking for smart devices that are lights and turning them all off. It’s goofy, but the Alexa programmers are trying to be “smart” by trying to control things within their system rather than using linked skills. The proof is basically that you used UD Mobile and it worked as expected. Meaning Alexa+ wasn’t using the skill at all.

Click the label next to the setting you are changing. That will update the setting. This is a change that UD introduced in 5.x many years ago and is discussed here many times. Don’t use the “write changes” at the bottom of the screen (for these changes). Also, some have noticed that if you set a specific on rate or other settings I might not show on that device the next time admin console loads as there seems to be a display issue. No known workaround known for that issue.

Okay, thanks.

No, eisy-ui uses the default http port 80. You'll probably need to open a ticket with UDI

IP address doesn’t work, either. Do I need to enter a port as well?

You won't see a link for eisy-ui in IoX finder. Try your eisy's ip address directly, such as: http://192.168.0.123

Successfully upgraded my EISY to 6.04 and everything seems to be working, however when I try to use http://eisy.local or https://eisy.local, I get "connection refused". IOX Finder only displays the usual port 8443 url for the admin console and nothing more. How can I confirm I have eisy-ui installed, and if needed, install it? Thanks

If you'd be using this on an ongoing basis, then developing a log parsing program would be your best bet. Yes, you'd have to have a scene to device id table to catch the scene equivalent commands.

The log as I recall (but no sure)is recorded by device and not scene so on or off for a scene translates to devices going on off. I’d likely write a program to parse rather than do it in excel. As to writing programs, it would be a task but if you triggered on device change that still happens if a scene caused the change.

Well, I have 85 switches so that's a lot of programs to write. Also, this has the same issue with lights on multiple scenes as below. The log file is a sort of solution but loading this in excel and then massaging the data so that I can compute on/off combos is time consuming, and the results have a lot of incorrect info because the log records switch actions, and lights on multiple scenes may be turned on by one switch and then turned off by another. So the script parsing the data would need to know the lights which respond to "all off" for instance.

Thanks for the tip, Ed! I was able to "Query:" a couple of devices that IoX couldn't reach and then "Write Updates to Device" and it worked! However for others, it didn't work; the query didn't result in a "1011" icon, and "Write to Device" and "Restore Device" didn't restore the connection with IoX (though the devices still work fine with local control and local links). I did find that for at least one of my wall switch dimmers, I had to long-press the tiny clear button at the bottom to go into linking mode before "Write Updates to Device" would work, but then the red ! went away and I could turn on and off via IoX. However, for several devices that were accessible to my old PLM, "Query" didn't result in a "1011" icon at the left. I found that one of the lamp modules that worked fine with the old PLM wouldn't respond to the "Write Updates to Device" or "Restore Device" so I long-pressed the linking button and then tried "Write Updates to Device" which failed, and then "Restore Device" which also failed. I checked its programming with the four-button wall switch that controls it, and that works fine. But many other devices are refusing to speak with IoX or vice versa, no matter which of the above I have tried. So I am at a loss for understanding why IoX cannot access it through the new USB PLM.

Further update: I was able to factory reset both keypads, which restored them to control their connected load with the top button. With that fix I was able to get zones all configure. It would be good to be able to set which button controls the local load from eisy-admin is there any chance that will show up in a future revision? Also I can not change any of the flags associated with these keypads. If I make a change and click the "Write Changes" button nothing happens, no "System Busy" popup or other indication of activity and if you refresh the device the flag dropdowns revert to the previous state.

Maybe look at the logging as I believe it records off / on and time of event.

Yes, you could write a program (per switch) that looks for control on events and increments a variable every time. Then at midnight have another program email you the variable value, and reset it to zero.

Is there a way to generate report on total on / off time as well as use during day/night, etc? Or some other way to get a sense of which lights are on most often?

That's perfect. Thanks!

Interestingly, for me, with a 2024 PLM (same revision I think), switching on and off did not work on any of the devices, but clicking on query worked for all of them to generate a 1011 icon to allow write updates to device and connect.

Not exactly what you asked but I use create topology which is html representation of all devices a scenes.

@dbwarner5 said it well. The key point is, you can only make buttons go on and off as part of a scene that gets activated, manually or programmatically. There's no way around that, and it seems to be the thing most people forget when they haven't programmed their Insteon devices in a long time. Or if you're coming from a Lutron background, where the processor always tracks the state of all devices and turns on LEDs whenever the corresponding devices are in the correct state, no matter how they got that way. If you want that kind of behavior, you have to write the logic yourself. -Tom