TriLife

Here you go @TomJ, https://github.com/Trilife/udi-mqtt-pg3x

Hi @TomJ There is a description of the other Tasmota devices (temp, humidity etc), which can be operated with the MQTT plug-in. I'm away from my computer right now, but from memory: From inside PG3 click on Details of MQTT plug-in, then click Configuration. If it doesn't come up right away above tue config parameters, there should be a button to display tye configuration Details. If for some reason they do not show up, please let me know and I'll point you towards the GitHub repository. Cheers.

@Geddy, I went hunting and did indeed find the ud*.state files in C:\Users\{username}\AppData\Local\Temp. Went ahead and deleted them too. Also increased java memory to 1024m. Thanks for that hint. @Techman, if Norton can delete them, can I not do so manually as well? The /temp folder is close to 6GB! I used to have System Mechanic, which did do clean-up chores like this, but didn't bother install it on my new rig. maybe I should install it again. Update: I used Windows Disk Cleanup, which includes deleting temporary files. All in all close to 8GB. Good riddance. And I enabled Windows Storage Sense, which will do this automatically in the future. Thanks to both of you again.

Thanks @paulbates, I guess I need to practice my patience some more. Unfortunately I have no Insteon at all. Only Tasmota and Zwave. Cheers

@Geddy, Wasn't there talk a few months ago that the Admin Console was being deprecated in favor of something more modern?

Thanks @Geddy, No ud*.state files anywhere, but after I added '-Xmx512m' in the runtime parameters in Java, AC started showing up. another case of little patience (so typical for me). Cheers!

Thanks @Techman. I found temp/ but didn't locate any ud*.state files in there. But late last night, after not touching the PC for a long while, the AC showed up, with a different color scheme. Go figure. I had added the runtime variable to speed up the script. This morning, after reboot, the AC showed up right away with the correct color scheme. Go figure. Case closed.

Hi @vandy, Glad you figured it out. I'd replace "cmd_topic": "cmnd/sensor/POWER"}, with "cmd_topic": "cmnd/sonoff01/POWER"}, for consistency's sake. In this particular case it doesn't matter, since the s31 type will never issue a cmd_topic.

Thanks @Techman, I went through the links, looking for differences. Can't seem to get it to work. Like I said, once I try to launch the AC LAN from within IoX Launcher, it thinks for a while and then the icon of the IoX Admin Console appears in the task bar. when I hover over it I see the name in the title bar and a white panel. There is a single line in that white panel, but it is too small to read. When I hover over the white area, all open windows on my screens disappear. This is normal behavior in Win11, except that the only the affected window should show... which makes me think that the program is running, but not displaying...

No changes to the PC other than regular Win11 updates. This setup was working properly before

I tried to access my eISYs today, going the usual route of clicking IoX Launcher on my desktop. It found both boxes, but when I click on one to launch AC console LAN (or any other option for that matter), it hangs: - an Icon appears on the task bar, after it thinks for a while, but whey you try to expand the window, nothing happens. Went browsing to through the forum, uninstalled and reinstalled latest Java, cleared caches, downloaded start.jlnp, rebooted computer etc. I even turned off all but the main monitor, thinking the window might be hiding somewhere (happened with Fusion 360), to no avail. Iox is on 5.9.1. I can access PG3 and I can SSH onto both eISYs. And, once I try to start AC console (with no success), I have to kill the IoX Launcher via Task Manager. Now other way to terminate it. Any ideas? There was some traffic about getting rid of AC console etc a few months back. Sure would be good... Cheers

Hi @Vandy, I'm back to workstation! So here is the scoop for having different nodes for the same device: devices: - id: "Test4CH1" name: "Friendly 4CH1" type: "switch" status_topic: "stat/Test4CH/POWER1" cmd_topic: "cmnd/Test4CH/power1" - id: "Test4CH2" name: "Friendly 4CH2" type: "switch" status_topic: "stat/Test4CH/POWER2" cmd_topic: "cmnd/Test4CH/power2" - id: "Test4CH3" name: "Friendly 4CH3" type: "switch" status_topic: "stat/Test4CH/POWER3" cmd_topic: "cmnd/Test4CH/power3" - id: "Test4CH4" name: "Friendly 4CH4" type: "switch" status_topic: "stat/Test4CH/POWER4" cmd_topic: "cmnd/Test4CH/power4" the above example shows a Sonoff 4 Channel switch. Note that the 'Test4CH' is the TOPIC name you gave your Sonoff and MUST BE THE SAME for everything you access on the same Tasmota device. It can be different from the 'id' you assign. In your case you might have a node 'id: "S31Switch" for the switch and a node 'id: "S31Sensor", entries would have a topic of ".../S31Device/..." in their message strings, because the device has only ONE TOPIC and will publish with that. All of this is in the configuration instructions, but in reviewing it, I do see that it is faaaar from clear. I apologize for that. The instructions definitely are in serious need of a clean-up. I would appreciate any feedback on this, so I can iterate. Cheers.

Hi @maxnorth, Glad you figured it out. I will add this to the to-do list for an update. Need to read up on the .MD format as well. As I recall there are/were some compatibility issues with the way PG3 displays more complex layouts...

Thanks @Geddy, @maxnorth, @sjenkins. Good teamwork.

Hi @vandy, [ {"id": "sonoff1", "type": "switch", "status_topic": "stat/sonoff1/POWER", "cmd_topic": "cmnd/sonoff1/power"}, {"id": "sonoff2", "type": "switch", "status_topic": "stat/sonoff2/POWER", "cmd_topic": "cmnd/sonoff2/power"} ] Please use this template for the dev list. There is no leading *device* in front of it Give that a try