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

Hi @vandy If you look at the page of the screenshot with the 5 configuration parameters, there should be a full set of instructions on how to create a devfile. Also try to click MQTTs INFO button in the Plug-in store, which should lead you to the configuration instructions... If you don't know how to save files to eISY, you may want to poke around the forum to familiarize yourself with SSH, putty, MobaXterm etc... I'm not close to a computer until the end of the month, so unfortunately I'll be of limited help. Sorry about that. Cheers

Have you created a device file (.yaml), saved it on the eISY and pointed your devfile to it (last config parameter)?

Hi @vandy, I'm traveling at the moment, won't get to my rig in a couple of weeks to help with specifics. Looking at your screenshot though, you seem to have problems with accessing the UDI Forum, is that correct? Were you able to install the MQTT plug-in (node server) and configure it, so it says "connected" in the PG3 home page? If so, when logging into the Admin Console, you should see an entry called MQTT on the left side panel, which shows all the devices you added during configuration of the plug-in. Let me know how you progress. Cheers

Hi @arcox, I'm away from my rig until end of May, so I'll try to help you from memory... A few things to point out: 1- there's no restriction to using the eISY broker at all. Point your devices (Arduino) to the same IP address as the eISY and use 1884 as the port! 1883 is used for internal comms. ## ONE OF THE BELOW IS REQUIRED (see below for example of each) devlist - JSON array, note format & space between '[' and '{' or devfile - name of yaml file stored on EISY ## THESE ARE REQUIRED ONLY IF USING AN EXTERNAL SERVER OR YOU CHANGED LOCAL SETTINGS mqtt_server - (default = 'localhost') mqtt_port - (default = 1884) mqtt_user - (default = admin) mqtt_password - (default = admin) 2- the MQTT plug-in is designed mostly for Tasmota-flashed devices... so it might require some tweaking on the Arduino side. The devfile.yaml should look like this: devices: - id: "Wemos32" name: "Wemos SW" type: "switch" status_topic: "stat/Wemos32/POWER" cmd_topic: "cmnd/Wemos32/power" 3- note that the yaml structure you show is quite different from the above. Let me know how this goes. Cheers

Hello @heardc, Thanks for reaching out. The MQTT plug-in was originally designed to control Tasmota-flashed devices like SonOff. Some creative users have figured out that it can also work with ESPHome. You are the first to try it with Frigate! A few pointers to try and get it to work: If you have the device type configured as "switch", sensor_id will be ignored. sensor_id is for "analog" types only (see bottom of Configuration notes) Not familiar with Frigate's naming conventions. In Tasmota the ID is used in the message, not the NAME. I'd try something like this: - id: "drivedet" name: "driveway detect" type: "switch" status_topic: "frigate/drivedet/detect/state" cmd_topic: "frigate/drivedet/detect/set" The MQTT plug-in will be listening to its messages and look for a topic "frigate/drivedet/detect/state" being sent by frigate (or your camera). If it matches that topic EXACTLY, it'll look at the value of ON/OFF. Likewise, if you click to SET, it will SEND a message with the topic cmd_topic: "frigate/drivedet/detect/set"... QUERY really wouldn't work here, because it is customized for TASMOTA. It sends a topic requesting information, which is completely different from status_topic or cmd_topic. It seems rather unusual that an MQTT plug-in generated message would delete anything, especially that the topic sent by the plug-in is highly unlikely to match a topic monitored by Frigate. Is there a way for you to monitor the MQTT messages being picked up by the Frigate? Cheers.

Hi @polo2883, can you enlighten us on what the issue was? Trying to fix the same issue here. Thanks

Same issue here. upon upgrade the router didn't recognize the eISY and assigned it a new IP. But even after reassigning it to the original slot, IoX refuses to connect, even with entering the IP address. SSH connects (no change in password) and shows that OS was upgraded to 14.1-p6. The odd thing is that I did the same upgrade on my development eISY a couple of weeks ago and it happened without a problem. Came right back up. Filed a ticket #26607 Cheers.

Hi Flex, I'm not familiar with the Control by Web x410. Your Polisy will be the broker. You will not need a cloud broker. Older versions required you to start a separate broker (Polisy and IoX also use it). I'm not sure if the newer versions did away with this. Just make sure you use 1884 (most default to 1883, which is in use.) It should not require a userid/password by default. But you might use your Polisy credentials, just in case. Also, as a heads-up: the MQTT plug-in is meant mostly for Tasmota-flashed esp devices. It somewhat works for ESPHome-flashed devices as well, and a series of custom developed devices. So, if you have a means of configuring your Control by Web to emulate a Tasmota device, or if you know what the typical publication of CbW is, you can give it a shot... As far as "how does MQTT work" is concerned, go to tasmota.github.io. They do a pretty good job explaining MQTT as it pertains to home automation... And since the plug-in is optimized for Tasmota... Finally, think about upgrading from Polisy to the eISY... If you use it, the MQTT broker runs by default. Very easy to set up. I think @Michel Kohanim has some specials running to make it less onerous on the wallet. I made the jump a while ago and couldn't be happier. Any questions, I'll gladly try to help! Cheers

I'll make sure to add this to the instructions on the next iteration.

Hi, you're close! Replace "POWER" with "POWER1", ..2 ..3 .. 4. For each switch you're trying to control... In case you need to controll ALL on/off, create a 5th device and use "POWER0". I'm away from my computer right now. You might want to follow the instructions on lower/upper case for POWER... Tasmota doesn't care, but the MQTT plug-in might.