Hi
I have a very basic - maybe stupid - question about the integration of my Shelly device: what is the difference between ShellyForHASS and the “official” Shelly integration? Which one should I choose? Or do I need both? What are the differences, pros and cons? Or is one a superset of the other? Will ShellyForHASS be integrated in the official integration? Maybe someone could bring some light into the dark… 
Hava a great day!
Thorsten
yap having the same doubt. for example does the official shelly integration already supports shellyEM? maybe a list of specific supported devices would be nice to have. and a comparison between the two approaches
The official Shelly integration has the beauty of being shown and configured automatically just after the device is powered and attached to the local network. But since it is local polling, needs a few seconds to refresh status of the device : slow for immediate action (ha 116.4, Shelly 1.8.5)
I’ve juste switched my 9 Shelly devices from ShellyForHass to full MQTT integration.
It took me some time, I did everything manually. But now eveything works perfectly. It’s instant and I think resources are better used this way.
Do both integrations have the same functionality? Why should I use the one over the other?
Why use MQTT if there are two direct, native ways to control the Shelly devices?
Because both integrations rely on polling mecanisms. MQTT does not : the module pushes an event whenever it needs and that’s it. Simple and efficient.
Ah. Ok. Thx. Never thought in that direction…
This is not true. ShellyForHASS uses CoAP, which publishes state changes from clients (switches,…) to the server. Only if CoAP doesn’t work, polling is used.
According to GitHub - StyraHem/ShellyForHASS: Shelly smart home platform for Home Assistant
Using mDns discovery and polling if CoAP not working (slower status updates) (0.1.5)
And Welcome to Shelly Technical Documentation | Shelly Technical Documentation
Every device should periodically publish its status using multicast packet in the form of non-confirmable request with code
0.30and request path/cit/s.
Oh really ??!! Nice to know. 
I got this exact answer on other threads and I did not dig in to check by myself indeed.
Thank you for this information.
If you just want to turn on/off switches from HA or the switch in Shelly always controls the relay connected there, then the official Shelly integration works fine and is fast because it just calls the switch and turns it on/off. However - if you rely on instant updates of the status of the input switches, status of relays etc - then the official Shelly integration is slow, polling is done very 30 seconds in my tests, so sometimes you will turn a relay/switch on and its status will be updated in HA in 30 seconds. If you want to use a Shelly switch in detached mode, this is a deal-breaker - I wanted to turn two lights (not connected to shelly relay) when a switch is flipped, so I made an automation monitoring the switch input (if switch is on or off). Needless to say - a random 0 to 30 seconds delay before lights turn on/off sucks. There’s a way to do it with the official integration - using events - but then it only works with momentary switches, because it generates events - short, long, double etc - but if your switches are constant on, constant off - then the events don’t work.
TL;DR switched to ShellyForHASS - it works much better in my case, the status of the input switches is updated instantly and that’s all I needed.
Me too! I also stayed with ShellyForHASS.
Since it is still confusion for users, are there ideas to merge both integrations?
Yeah -several hours working away trying to work out which I should use!
I would be really helpful if Shelly For Hass would just come out and say at the top of its home page that ist an alternative integration to the native one. I think its actually supported by shelly and is in active development and may provide more features than the native.
I connected my shelly devices to the net using the AP and the internal web servers, added shelly: to my configuration.yaml and it found things nicely. But update seems slow and I cannot get the shelly.click event to fire from the button.
So its time to try shelly for hass
Is it possible (using the native Shelly integration or ShellyFor HASS) to use click events of a detached switch to perform dimming on another light?
I have a Shelly 2.5 with no outputs, only two momentary switches connected (configured as detached). I want a long press of one of the switches to “dim” another non-shelly controlled light (that light is controlled by ESPHOME) in my house. However AFAICT there is only a single or long click types with no way to discover the duration of the click. Nor is there a down_click nor up_click event type.
Is this possible in any integration?
I have been bouncing between these options as well, and have decided to just go with the MQTT method. I was having delayed status changes as well as not seeing the shelly.click event no matter what I tried. The shellies_discovery script for MQTT takes a little bit of manual setup, but now I have very immediate status changes. I wasn’t super familairt with MQTT before and was wondering which one would be faster, and MQTT does seem very responsive. so if anyone else is trying to decide based on these factors, maybe just go with MQTT.
After a long period of delays between my Shellies and HA I found out, that setting “CoIoT peer” in my Shellies helps. This option switches the Shelly from multicast to unicast, when the Shelly sends the status messages. Before this, it took 30 seconds and longer until HA recognized the new change.
What is the current status, which of these integrations is preferable?
I’m currently using ShellyForHass, as I’m currently having only 4 active devices. But I just received batch of 14 new devices (plus 3 existing, not yet installed ones), which I should install to my house, and before starting this, I would need to decide, which integration I would use later on.
I have moved to the integrated Shelly rather than shellyforhadd. Mainly just for future support and updates. All us working really well with my Shelly 2.5’s 1’s em’s and motion
I’m still on Shelly4HASS, mainly for historical reasons. But if I had to reinstall HA from scratch, I would recommend the integrated Shelly implementation.
Can anyone else elaborate on their experiences with the current CoIoT vs MQTT. Is the prior capable of superseding mqtt or is the integration just better supported?