Guy Lavoie

Before the holiday period is over, make sure you enjoy the festivities by having your Polisy participate in the entertainment. For this, ssh into it, and first adjust the permissions on the speaker device: [admin@polisy ~]$ sudo chmod 622 /dev/speaker Then let 'er rip: (highlight the line below, starting with "echo", do ctrl-C to copy it, then go to your ssh window and do ctrl-V) [admin@polisy ~]$ echo "t165l8epepl4epl8epepl4epegcdl1e l4fffl8pfl4feepeddel2dg l8epepl4epl8epepl4epegcdl1e l4fffl8pfl4feeeggfdl2c." >/dev/speaker Of course, for the best sound, you need to be using Monster network cables! Sorry eisy owners, you're out of luck this time!

I also bought a Echo G4 for the same reason.

Bring up the device you want to map, tap on the three dots at the top right, and select "Configure Advanced Status Color, etc". You'll get the mapped values screen.

A question pops up in the back of my mind: is it even possible to program (link) a switch send an Off command to another switch when turning it On?

To rule out IoX (your controller), just unplug the PLM temporarily and redo your tests. If things stay the same, then it's not a program.

12 volts is 12 volts, nothing magical. I think the warning is because of the USB C connector used for the power connector. For the average tech stuff user, you would usually assume that any power supply with a USB C connector "should do", especially with some power supplies that sense and automatically adjust to the required voltage. It isn't the case with this PC. I'd almost be more vary about accidentally plugging the power supply into the actual USB C port on the eisy.

I've also noticed that, though I've only done it once or twice since that change

Yes, however there is now a several seconds long delay where the screen stays blank when you first fire up the app and when your device list appears, device statuses are already updated. Sounds like there is a silent sync of the displayed devices during that blank time. Not a bad idea really if that's the intent.

You won't be able to do that with a program node as a favorite. If you tap on Display Status, you'll see that the options only pertain to program related choices, like the last time it was run, things like that. To do what you want, you would be better off having your favorite change something like a variable, or a virtual switch type node. The display options then allow you to display the value or status of that node. You can also have it change the color of the icon based on value. The variable value or virtual switch status or control event could then be the trigger in a program (or programs) to launch a scene or whatever.

I haven't tried this myself but you would start by adding a favorite, selecting "program" as the display node, and then select the program. In admin console, you would set that program to "disabled", so that it only runs when you ask it to. Give that a try.

Interesting. Maybe UDI caught wind of some of the user frustrations with the default switch of login methods and decided to display both options to soften things up.

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.