Guy Lavoie

Ok thanks, that clears up a few things. As for the portal duplicates, I've been experimenting with a unit, setting it up over and over again as part of my tests, and when I upgraded it to 6.0.4 and accessed it for the first time, it asked me to log into the portal, where it added itself to my account. This is likely part of the new login scheme with the portal credentials, to keep things consistent. As @DennisC said, you can easily delete any extraneous entries by clicking on the "x". Release 6.0.2 was probably the initial release for the newer R2 version, and I don't think was ever released as an upgrade for the older eisy or Polisy versions. Seems we went straight from 6.0.0 to 6.0.3. Are you also saying that the same unit appears twice in IoX finder (without you manually adding any entries)? That would be new. Some of us have been manually adding such duplicate entries, one with the port number and one without, to have both login methods readily available.

Several things aren't making sense here. If each eisy could be seen with it's own IP address, then they certainly had their own unique MAC addresses. The MAC address is burned into the network interface chip during manufacturing. If you look at your router's connected devices list, you'll be able to see the MAC address of each eisy. You can certainly have more than one eisy on a network. I have an eisy and two Polisys right here, all getting along happily. Another thing is that a new eisy usually come with one free year of portal access. Sounds like some confusion happening between your existing eisy and the new one in the portal menu. Things aren't always clear. The fact that they are R1 or R2 isn't relevant, they are functionally the same. I'd start by connecting both to your network again and looking at the router device table to be sure, and note the MAC addresses, and then write them down, and maybe put a sticker under each unit with it's MAC address. The Polisys had that, and it was useful. Then go back to the portal and make sure that they are both listed with their portal access.

Yes, you can connect a screen (or two) and keyboard, and log into admin, just like a ssh session from a PC. It can also come in handy for troubleshooting if networking isn't coming up for some reason. I have Insteon water leak sensors in my setup, to control a zwave watercop valve. Yolink also has sensors, and other makes.

Living with X10 requires you to be ready for things like that. Good going.

Well all line powered LED lighting devices have a ballast of some sort, to bring down the voltage to the few volts that LEDs need. This one just happens to be creating noise that X10 doesn't like. That's not rare. The easiest solution is to replace it with one that works ok, if it's not too expensive and/or troublesome to do so. Otherwise you'd need to get some sort of X10 line filter between the switch and the light. For your second question: Different devices have different sensitivities, and can also depend on how physically or electrically close (eg: same circuit breaker) they are to the device producing noise, or absorbing X10 signals. This problem has been the main issue with X10, and much of the reason for newer protocols and communications standards. Still, X10 is still around 49 years following it's introduction. It's had a long life!

But you're one step too far. Before we can say that the eisy isn't "seeing" the Off command, we need to see what the event viewer says. If it does receive the command, but doesn't produce the result you expect, then it's something else, like a program logic issue, or something else down the line. Now that one switch is an X10 switch? What does control? Incandescent bulbs, LED bulbs? Could the switch or whatever it's controlling be causing line noise? If it's easy enough, try removing the bulb or whatever but leave the switch itself on, and test again.

But does the event viewer in admin console show reception of the On commnd? The Off command?

If the X10 wifi interface is also not seeing the off commands, then it's a problem with the keypad. Tried it with an ordinary X10 module, plugged in close to the keypad?

Ok, thanks for the quick respone!

Misery loves company! Seriously though, that's "good news", in that it appears to be something external. Interesting that just a restart of your otherwise already working system caused it to fail in the same way. The fact that it's failing when getting location properties seems to indicate that it's something it only does once, upon startup, like a discovery process. We'll wait to see how it plays out. Thanks for checking this out (and unfortunately breaking yours)!

Well my location settings look good. Right geographical location and time zone. Other things I've just tried: setting up the plugin on another eisy. (running the same versions), adding a second Emporia plug in the app. Getting the same error, on both eisys. Does anyone else have this running ok on a eisy with 6.0.4?

Well I already had the development packages installed, but then I thought that maybe they didn't get updated along with the OS update that came with IoX 6.0.0 so I clicked on Install Dev. Packages again (with a tail -f on /var/udx/logs/log to see if anything happened). It did in fact update lots of "14.3" files. Update successful. Then I restarted the plugin, and the error remains the same: 2025-12-27 10:07:36.821 Thread-2 (parameterHandler) udi_interface ERROR vue:parameterHandler: Discovery failed: 400 Client Error: for url: https://api.emporiaenergy.com/devices/544523/locationProperties

I just installed this plugin. I bought some Emporia power monitoring plugs, configured one (working fine in their phone app). After setting up the account name and password in the plugin, it's not seeing the device. I'm getting the following in the error log. Any hints as to what might be wrong? I'm running on the latest versions (IoX 6.0.4, PG3x 3.4.9) Now I'm seeing the same messages but each one repeated 4 times, on 4 lines. 2025-12-26 20:33:17.369 Thread-2 (parameterHandler) udi_interface ERROR vue:parameterHandler: querys is type <class 'query.Query'> 2025-12-26 20:33:17.744 Thread-2 (parameterHandler) udi_interface ERROR vue:parameterHandler: Discovery failed: 400 Client Error: for url: https://api.emporiaenergy.com/devices/544523/locationProperties 2025-12-26 20:34:09.596 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message longPoll 2025-12-26 20:34:09.597 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING longPoll 2025-12-26 20:34:09.597 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS longPoll message {} from Polyglot 2025-12-26 20:34:09.670 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2025-12-26 20:34:09.671 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2025-12-26 20:34:09.671 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS shortPoll message {} from Polyglot 2025-12-26 20:34:17.751 Thread-2 (parameterHandler) udi_interface INFO vue:parameterHandler: Logging in to Emporia Cloud 2025-12-26 20:34:19.681 MQTT udi_interface.interface DEBUG interface:_message: QUEUING incoming message shortPoll 2025-12-26 20:34:19.681 Command udi_interface.interface DEBUG interface:_parseInput: DEQUEING shortPoll 2025-12-26 20:34:19.681 Command udi_interface.interface DEBUG interface:_handleInput: PROCESS shortPoll message {} from Polyglot 2025-12-26 20:34:20.883 Thread-2 (parameterHandler) udi_interface INFO query:__init__: Query class initialized 2025-12-26 20:34:20.884 Thread-2 (parameterHandler) udi_interface ERROR vue:parameterHandler: querys is type <class 'query.Query'> 2025-12-26 20:34:21.326 Thread-2 (parameterHandler) udi_interface ERROR vue:parameterHandler: Discovery failed: 400 Client Error: for url: https://api.emporiaenergy.com/devices/544523/locationProperties

Sounds right. The upgrade would now be updating all your modules to update their links to the PLM, so they can "call home" to the new device id. The PLM itself will have all the module addresses it needs to know about also written to it.

Two windows pop up simultaneously?

If it ain't broke, don't fix it. That's also my usual approach. I was just pointing out various ways you can test for dates for the original poster. 😃

There is a free plugin called "Holidays" that allows you to define holidays, that you can then use in program logic. The instructions are rather cryptic, but I'll get around to figuring it out sometime. You can also put dates as part of scheduled events. If you uncheck the "daily" box, an extra field appears where you can choose dates from a calendar. You can specify a "from" and "to" date range, so you can use that to set a variable as a flag to indicate a holiday day, interval, whatever you like.

My first aid kit is always ready: a usb drive with a recovery image, a screen and keyboard, and several types of backups. Remember, there are two groups of computer users: those who have lost data, and those who will.

Another thing you mention in your original post: an echo dot isn't a border router. Matter uses IPv6 for it's communications with devices, implemented over traditional ethernet/wifi, and also over Zigbee ("Thread" devices). A border router will bridge the two topologies. Here is a list of the devices that have that functionality: https://www.matteralpha.com/frequently-asked-questions/complete-list-thread-border-routers

The other hidden benefit of looking for control events (instead of status change) is that it allows you to separate the status display from triggering action. In other words, you can have a program update the status of that device, which will show in UD Mobile, without triggering the control event that you would get by pressing a button on it. Updating the status triggers a status change, but not a control event. This is the same benefit that you get with Keypadlincs.

What you've discovered is that at this point, eisy isn't very good at configuring (commissioning) a new Matter device, but it's becoming better at accepting a shared Matter device from another platform, like Alexa or Google home. That's how we mainly do it at this time. It's still in Alpha testing on the eisy.

The first step might be to try a "restore device" (right click on the switch in Admin Console to see that option). That should rewrite the links between it and the PLM. If that doesn't work, then the next step might be a factory reset of the switch and then relinking it to the controller.

Well that's what forum buddies are for! Seriously though, this wasn't very well explained in the release announcement. It took a bit of figuring out to get things working the "old" way. Changing the default login method automatically to the new one wasn't the best thing, and has caused lots of grief. A good idea, badly implemented. A pop up box offering the new method (with an option to choose it) would have been better.

There is no harm in having both eisy login methods listed if you plan on using eisy-ui and/or polyglot and/or the portal every now and then. Using the portal login makes going from one to the other seamless.

Try adding a new entry to IoX finder, to log in the old way (admin...). Click on Add, then enter the URL as (for example): https://192.168.0.123:8443/desc The port number 8443 will have it request your IoX login name (usually admin, admin) and password.