
TriLife
Members-
Posts
376 -
Joined
-
Last visited
Everything posted by TriLife
-
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.
-
Greetings from the other side of the world. @sjenkins, I'm wondering, if this can be solved by changing the name of the plug-in from mqtt-poly to MQTT... This would require me to remove the current MQTT from the Beta Store though, or point the MQTT plugin to load from your repository. I could do so early next week, when I'm back from my trip
-
I only access MQSwitch and MQDimmer with Google Assistant (Voice): when initially called on a hub or hub max, the screen shows the status as ON (and % for dimmer). And after a couple of seconds it reverts to OFF and 0%. When using the Google Home app, you can click a device to turn it on and the GUI shows ON and stays on. But if I independently turn the light off locally, the GUI remains ON, meaning that it doesn't get feedback from the plug-in, or doesn't process it properly. AC does report when a light gets turned off locally. Strong work on powering through all those items @sjenkins! Thanks so much
-
Glad that worked for you! If you have further ideas on how we can enhance the MQTT plug-in, please contribute on: We started on a list for you, in case you're shy😜 Cheers JR
-
Good morning @TJF1960, Couldn't keep @sjenkins away from his keyboard! THANKS! There is a for STATUS on the Beta Store MQTT plug-in. Now V39. your PG3 should notify you. just update... It also is on the Production Store, but since we didn't bump the rev, you might not get an update notice. Please let us know how it goes.
-
Good morning @TJF1960; Ok, 'MQTT' in the Beta Store is now the true blue V 0.0.35. I cloned the repository from GitHub, reverted to V35 and put it in its own branch. (I was reluctant to do this initially, because I am git-phobic 😜. Turns out using Github Desktop it was a breeze!) I also tested it. It reports status back to the AC. Let me know if this works for you. Cheers
-
Hmmm. I'll have a look at it tomorrow. In the meantime, @sjenkins may have a true-blue V35 in his back pocket, which he cloned to develop V39...
-
Hi @TJF1960. Yes, MQTT is V35 (although it may say V40 somewhere)
-
You're absolutely correct @maxnorth. I put those defaults in when I was expanding the plugin a couple of years ago. Some of those fields are necessary on legacy setups (isy994, polisy, PG2, etc). With eISY and PG3x, they have become defaults. I will ask UDI, how many users still are on legacy setups and we'll make adjustments as necessary. Thanks for the feedback!
-
10- simplify devlist/devfile by using 'defaults' for status_topic and cmd_topic. (They are mostly a combination of 'id' and a set of repetitive strings). This could reduce configuration pain by 80% and typos by 90%. Minimum need: 'id:' and 'type:' optional 'name:' 11- Google Assistant is not reporting device status consistently: it shows correctly for a few seconds and then goes to 'OFF'
-
devices: # SAMPLE SECTION - id: "Test1" name: "Friendly Test1" type: "switch" status_topic: "stat/Test1/POWER" cmd_topic: "cmnd/Test1/power" # TOPIC in Sonoff Quad MQTT CONFIG "Test4CH" Note no CH# and no UNDERSCORE ! - 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" # Hallway Box (IP x.20...) - id: "OfcBath" #{1:"Orientes", 2:"Interior", 3:"Sky", 4:""} name: "Office Bath" type: "switch" status_topic: "stat/OfcBath/POWER" cmd_topic: "cmnd/OfcBath/power" there you go. devices: is critical. every '-' starts a new device. I keep my file in /usr/home/admin/<file-name>.yaml May I suggest we move the conversation over to this for suggestions and general questions? Thanks
-
I wanna know, if your chickens are happy! 😄
-
good catch @maxnorth, the correct format is in the lines above "status_topic": "stat/sonoff1/POWER", "cmd_topic": "cmnd/sonoff1/power"}
-
Good morning everyone: @EWhite, @TJF1960, @maxnorth @sjenkins did a stellar job hunting down the bug overnight. Thanks! So, we decided on Option C : The production store now has V39 on it, which should fix the issues you have been experiencing. It did so on both my eISYs. A simple UPDATE in your plug-in will get you up to date. Sorry for putting you through this. I also managed to 'follow' the MQTT thread in the forum, so you don't have to mention me for me to get a message. There is an updated link in the CONFIGURATION for future comments. Keep them coming! Cheers.
-
Good morning @maxnorth, @EWhite. @TJF1960, @sjenkins As mentioned earlier, I was able to reproduce the error on two different eISYs here. (We have not yet identified the root cause) I also was able to revert back to V35 and confirm that at least on these two eISYs it works as intended, updating status when it changes. Now, we have a choice: A- V35 is available on the beta store under 'MQTT' (NOT 'mqtt-poly'!). If you chose to go there your functionality should return. But you will habe to delete the contents of your slot and reinstall from beta. or B- I can put V35 on the Production store and you should get an 'Update Available' in PG3. It will automatically install in your slot, no reconfiguration necessary. My preference is for B, since there are likely users out there, who are not necessarily monitoring the forum... PLEASE LET ME KNOW! If I don't hear from you, I'll back-rev the Production Store. @maxnorth: Sorry I didn't see your post about the s31. I don't have one of those to troubleshoot. I'm about to embark on a multi week overseas trip without access to a computer. I'll make a note to reach out to you upon my return.
-
the conversation seems to have moved to . Just in case. BTW, I was able to replicate here. some switches update their status on AC, the vast majority do not (i have 118 of them) I have been using V37 for a several days and can fairly confirm that the not updating of AC (and as a result non-execution of referencing programs) is only a couple of days old... Seems to be related with changing from Beta to Production store, as this may have forced some type of a reinstall... Working on it. If we can't find the root cause fairly quickly I'll suggest to revert to a stable version (V34 or V35).
-
Are you also deleting the nodes that were created? That sometimes causes problems. Go into PG3x, MQTT plug in DETAILS, then click on nodes. You should be able to delete all nodes except the controller node. Then do a stop/start to force the plugin to install them all. As an aside, after that restart, please observe the bottom right of the screen for a Red warning like " Error processing message from Xxxx die to high volume. Normally this should not pop up, unless you have in excess of 50-80 mqtt nodes to add. Thanks
-
I just checked bot my eISYs. Both report status on AC... Both are 3.2.22/5.8.0. Let's see what @sjenkins reports back
-
Hello all. We've been working on cleaning up the plug-in with a fellow developer, and it looks like we put some doozies in there. Let me reach out to him and see what's going on... Stand by @maxnorth, @TJF1960