The devil is in the details
Good to see it's working for you now.
Yes, or the devil is always in DNS or DHCP 
Beiträge von shellerr
-
-
-
Thanks for you help, thanks for making me inspect my network, I found the root cause !
It was a kind of IP conflict. One of the 4 interfaces of my Synology NAS had the same IP address of this Shelly. But that interface is disabled so I thought it wasn't used at all. My MQTT broker is running on the NAS so I guess it has an internal routing table there...
I changed the interface to DHCP and it's all good !
-
biomass ok I see. I don't have any rules...
-
If you want to try and debug the UDP traffic, have you already checked your router for the settings that apply to all your Shellies? I have an outbound NTP only rule for my Shellies for example, with my last setup I noticed I forgot to do *all* the settings for all the devices....
I'm sorry, I don't understand why my router might be involved because everything is inside my network, the router is to outside. Sorry if it does not make sense. Thanks.
-
66er I verified again and this is not my issue.
If I manage to setup the "UDP debug", would I see some details about the failing connection maye ?
Thanks.
-
> After every change, you 've to set the password new.
Yes I know, but I'll try once again to be sure
Thanks. -
Hi.
I have 15 shellies all connected to a (local) mosquitto broker. One of them (a Plus 1PM) won't connect.
They all use the same credentials.
I don't think it is an issue with the device because connecting it to "test.mosquitto.com" does work
I don't see anything in the mosquitto log so I was wondering if there is any way to have more details about a failure to connec or something on the Shelly side.
Thanks.
-
Ah yes I see, mine is a 1PM "Plus".
There must be something in the MQTT message to distinguish a physical interaction from a generic status update ?
-
Hi, probably a combination of these settings ?
-
Still working without issues.
Version is 6.0.21Thanks
-
Oh yeah I see, the `"input:0":{"id":0,"state":false}` part allows me de differenciate my button flip event from a "periodic" status update. Thanks !
> your MQTT configuration seems to be missing the port, should be 1883
Nope, as I use the default port, I can skip it.
-
I've just seen a NotifyEvent of type "config_changed" (just like you). So maybe my problem is that it does not fire an event for a switch flip ?
-
Damn! What am I doing differently then ? :p
I attached a screenshot of my MQTT config. Do you have also the two checkboxes checked ?
Thanks.
-
Freshmeat Still running well ? On which Unifi AP firmware version ? Thanks.
-
To my undestabding to this page : https://shelly-api-docs.shelly.cloud/gen2/General/Notifications it should be there.
> Have you already tested subscription to {prefix}/#?
Yes I did, only the NotifyStatus appear.
Thank you
-
Hi,
If I subscribe to
{prefix}/events/rpc, I should get bothNotifyStatusandNotifyEventnotifications, right ?I only get
NotifyStatusmessages. If I flip the (detached) switch, I don't get any message for that event.Am I doing something wrong ? Is it in an other topic ?
Thanks.
-
This is your problem, not the shellly.
Please use the search here in the forum. Unifi makes problems often.
Thanks for your advice.
After reading a lot of posts (including google-translated-from-german ones), I was able to make my Shellies work again. I updated my Access Points' firmware to an even older version (5.43.56.12784 from late 2021).
I'm sure that's not the version I was on before so there is still some kind of mistery in here but at least it works. I hope it'd help others.
-
I downgraded, updated back and then to an even newer version of Unifi Network : no change, all my shelly devices are "down" :-/
-
> If an option --> downgrade for verify
Yes I can try that, I'll have do document myself about this tho.
According to you, would the firmware or the controller version be the most likely culprit ?