Guy Lavoie

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.

Have you tried going into your phone's settings screen -> Apps, then finding the UD Mobile app, and clearing cache?

I had been holding off on upgrading my in-service eisy, which was still on 5.9.1. After testing 6.0.0. and 6.0.3 on a test Polisy, and seeing that the release notes in the sysconfig.txt file indicated only minor fixes for 6.0.4, I concluded that the new version must be stable enough to give it a go. So with lots of trepidation (and a couple of prayers) I went ahead and launched the upgrade. Of course, doing this on a day like Christmas would usually be quite foolhardy, with no UDI support readily available. But I have a eisy recovery image on a USB all set, and a screen and keyboard at the ready. So I started by doing a full cpio backup of my entire eisy to a USB drive first. In a nutshell, it worked out ok. I had to manually add the eisy back to IoX finder before I could see it. I added both lines for the IoX and portal logins. Then I took a quick tour of my system. Insteon was Insteoning, Zwave was Zwaving. Plugins seemed to be up and running ok. The only thing not quite working is eisy-ui, which isn't critical for me at this time. I indicated that in the appropriate forum section. I guess getting an updated recovery image would be a good next step, to keep my first aid kit up to date.

I just updated to IoX 6.0.4 and I did get the blank page in eisy-ui. Now I'm getting some things displaying but with errors. For example the Nodes page shows the nodes for about 2 seconds, then goes blank and shows an error 404. It displays the program list ok but if I click on any program, I get "error loading profiles" where the program listing should be. The System -> Upgrade page is showing all the latest versions ok.

What's not working is...my brain! Hehe, I just retested this and yes, it does generate control events. I've only been into the eisy for just over a year, so I'm still learning. That excuse will thus be expiring sooner than later 😀. I think that what threw me off was that initially I was testing it from admin console, before I got more into UD Mobile, where it really becomes more useful. It would be handy if UD Mobile allowed you to optionally display a switch as two little on/off buttons instead of default toggle, without needing to go into the switch's detailed menu. So Virtual just keeps getting better. Even more when you understand how it works! 😄

Yup, my mistake, Virtual does send control events too. I just retested it to my satisfaction. Sorry about the misdirection.

The fact that virtual devices don't generate control events can be worked around, by having the status change trigger a program that then resets the status after a short wait. It just makes things a bit more cumbersome.

Yup, that plus a few more Matter related fixes and improvements:

I guess triggering device changes from UD Mobile is indistinguishable from doing the same thing from Admin Console, right? It would have been nice if turning a virtual switch on or off from UD Mobile could generate Control events as well as Status change events, just like a physical switch. Wishful thinking?

One thing: the Virtual plugin doesn't generate Switched events, only Status changes. It would be handy if it could create Switched events too, but there is no physical device involved.