Beiträge von shellerr

Zitat

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

Resolved.

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...

Zitat

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.

Screenshot 118.pngScreenshot 119.pngScreenshot 120.png

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 ?

Screenshot 117.png

Hi, probably a combination of these settings ?

Zitat

Still working without issues.
Version is 6.0.21

Thanks

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 both NotifyStatus and NotifyEvent notifications, right ?

I only get NotifyStatus messages. 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.

Zitat

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 ?