Shelly-homekit: Getting "No response" from all shellys and after a retry all come back

[pivale]

Hey guys,

Not sure if this is a problem of my setup or if anyone is having the same issue.

From time to time (not always), when I open Home app I see all shellys as "No response" after a loading period.

If I close the app and return to it later (or if I leave it open for a while) the app will retry and get the correct status.

Some thoughts on this:

• I only have one router for the all house
• One of the shellys is literally 1 meter away from the router
• The WC ones are fibaro's and work using bluetooth
• It's not network or it would also lose connectivity to the apple tv or any other apps on my mobile
• It's all at the same time, the others respond correctly
• I'm not seeing this happening on only one or a couple... It's either all or none
• Maybe the calls on the shellys to get the status are taking too long and some other equipment (hub, for example) is also asking and the other call takes too long
• I think this is also affecting my automations, since some are not being triggered from time to time

Any ideas on what the problem might be? SW or maybe on my side...

[yehuda2525]

I have the same problem 🤔

[andyblac]

just started with iOS14.1 ?, is it just on phone or is Hub still detectig them ok ?

[pivale]

I don't recall having this before v2.3.0... Not sure if it's related
I'm on iOS14.1 but it was happening already on 14.0.1
The Hub is an Apple TV, I don't think I can check there, or can I?

[andyblac]

yeah tvOS has homekit iirc, double press home to get menu iirc.

[juancitomadrid]

I have been researching the subject for several days and it seems that there is no clear solution.
Some say it is due to the "multicast" option on the network.
Others say that "mdns" should be enabled when there is more than one network.
I have also read that there are communication problems between the different 2ghz / 5ghz networks.

I have installed the "Discovery" app and I can see that some of my shellys are randomly connecting and disconnecting.

[pivale]

yeah tvOS has homekit iirc, double press home to get menu iirc.

It's a long press and then you can enter a Home like menu, but only "Scenes" are available there.

[andyblac]

ah ok.

[socialsubs]

Hey guys,

Not sure if this is a problem of my setup or if anyone is having the same issue.

From time to time (not always), when I open Home app I see all shellys as "No response" after a loading period.

If I close the app and return to it later (or if I leave it open for a while) the app will retry and get the correct status.

Some thoughts on this:

• I only have one router for the all house
• One of the shellys is literally 1 meter away from the router
• The WC ones are fibaro's and work using bluetooth
• It's not network or it would also lose connectivity to the apple tv or any other apps on my mobile
• It's all at the same time, the others respond correctly
• I'm not seeing this happening on only one or a couple... It's either all or none
• Maybe the calls on the shellys to get the status are taking too long and some other equipment (hub, for example) is also asking and the other call takes too long
• I think this is also affecting my automations, since some are not being triggered from time to time

Any ideas on what the problem might be? SW or maybe on my side...

I had the same problem and after several tests, I basically solved it by setting the wifi channel manually. I have a Mesh network (2.4GHz + 5GHz) with one FRITZ!Box router and three FRITZ!Powerline.
Now the problem only occurs occasionally when I connect from outside then i just close and restart the app to get the devices back online.

[juancitomadrid]

I had the same problem and after several tests, I basically solved it by setting the wifi channel manually. I have a Mesh network (2.4GHz + 5GHz) with one FRITZ!Box router and three FRITZ!Powerline.
Now the problem only occurs occasionally when I connect from outside then i just close and restart the app to get the devices back online.

I have not tried putting the 5ghz channels in manual (only 2ghz). I will try, thanks for exposing experience.

[pivale]

I have not tried putting the 5ghz channels in manual (only 2ghz). I will try, thanks for exposing experience.

The Shellys use only the 2,4ghz band, so changing the 5ghz shouldn't affect.
If you try it, let us know of the results

[andyblac]

i found that it best to keep a totally seperate SSID for IoT on fixed 2.4Ghz, as some router / AP's support combining band into one SSID with a prefered band aka 5Ghz, but this can cause issue with some IoT devcies, even though the they do not support 5Ghz the router / AP still tries to attach that device to 5Ghz, and thus the device can drop connections as the AP tried to move it to the other band.

[juancitomadrid]

The Shellys use only the 2,4ghz band, so changing the 5ghz shouldn't affect.
If you try it, let us know of the results

i found that it best to keep a totally seperate SSID for IoT on fixed 2.4Ghz, as some router / AP's support combining band into one SSID with a prefered band aka 5Ghz, but this can cause issue with some IoT devcies, even though the they do not support 5Ghz the router / AP still tries to attach that device to 5Ghz, and thus the device can drop connections as the AP tried to move it to the other band.

As @andyblac says, although the shellys only use the 2ghz band, the problem (I think) is in the AP and the connection with the bridge or the other devices.

Now I am going to configure an exclusive network for Iot in 2ghz and we will see if it improves.
https://youtu.be/ptqa7JXbS5U

However my connections are random and it almost always happens when I am connected to a different AP than the one the shellys are on.
For example, if I go down to the basement with the iPhone and open the home app, I immediately see the shellys that are connected to the AP in the basement, but many times I also see the others ... at times it "sees" them and at times it doesn't.

[andyblac]

@juancitomadrid to me your issue sounds like a switch issue more than an AP issue, i am not an expert but, it does sound like the switch is not handling Multicast very well between all your AP's.

just for info i use a Unifi switch and Unifi AP's

[rojer]

so, i have a theory that our Bonjour/DNS-SD advertisements get lost sometimes and the records expire. we only advertise once during the TTL period (2 minutes).
can you try this firmware: https://rojer.me/files/shelly/2.4.0-beta2/
it has more frequent advertisements (every 20 seconds instead of every 60), hopefully enough will get through so records don't expire. @juancitomadrid can you try this one over the next few days and let me know if it's any better?

[andyblac]

@rojer related to this ? https://github.com/mongoose-os-apps/shelly-homekit/issues/108

[rojer]

yep, possibly.

[juancitomadrid]

@juancitomadrid to me your issue sounds like a switch issue more than an AP issue, i am not an expert but, it does sound like the switch is not handling Multicast very well between all your AP's.

just for info i use a Unifi switch and Unifi AP's

Can you explain this point please?
This is my Setup:

I have Tp-link switch, I don't know If I can change something on it.
I can configure on edgerouter I think.

[juancitomadrid]

so, i have a theory that our Bonjour/DNS-SD advertisements get lost sometimes and the records expire. we only advertise once during the TTL period (2 minutes).
can you try this firmware: https://rojer.me/files/shelly/2.4.0-beta2/
it has more frequent advertisements (every 20 seconds instead of every 60), hopefully enough will get through so records don't expire. @juancitomadrid can you try this one over the next few days and let me know if it's any better?

I going to do now!
Thanks @rojer !!!

[andyblac]

@juancitomadrid looking at the diagram, and am i correct in saying that the basement Shelly, is the one that is the issue ?, as that is the only only one on the TP-LINK switch, so it does indeed piont to the issue being releated to the switch. i take it is a simple unmanaged switch (ie layer 1 only)

[juancitomadrid]

@juancitomadrid looking at the diagram, and am i correct in saying that the basement Shelly, is the one that is the issue ?, as that is the only only one on the TP-LINK switch, so it does indeed piont to the issue being releated to the switch. i take it is a simple unmanaged switch (ie layer 1 only)

You are right...
This is my switch (thinking of changing it for one of unifi).
https://www.amazon.es/gp/product/B00JKB63D8/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

[juancitomadrid]

@rojer since I installed the beta 2.4.0 beta2 (25 min ago) I have not had any disconnection ...

The weird thing is that I see in the Discovery app that if they disappear from the "_hap._tcp."

[andyblac]

@juancitomadrid looking at the diagram, and am i correct in saying that the basement Shelly, is the one that is the issue ?, as that is the only only one on the TP-LINK switch, so it does indeed piont to the issue being releated to the switch. i take it is a simple unmanaged switch (ie layer 1 only)

You are right...
This is my switch (thinking of changing it for one of unifi).
https://www.amazon.es/gp/product/B00JKB63D8/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

yeah it a simple dumb unmanaged switch, it won't help, it probably not handling multicast / MDNS very well.

[rojer]

@juancitomadrid 25 minutes is not much of a runtime, let's keep monitoring.

[juancitomadrid]

yeah it a simple dumb unmanaged switch, it won't help, it probably not handling multicast / MDNS very well.

I thought that was managed on the router or in the unifi controller.

[andyblac]

yeah it a simple dumb unmanaged switch, it won't help, it probably not handling multicast / MDNS very well.

I thought that was managed on the router or in the unifi controller.

no, switches are self managed. if they are layer 2 / 3, unifi switches do get managed via unifi controller, but it has no effect on other manufactures switches.

[juancitomadrid]

Still working perfect for me @rojer

Before this beta. He had cuts every very short time.

It is also true that I did something else. Create a new network (with new ssid) and connect the shellys to that new network. Then I removed it and reconnected them to the main network again. Perhaps this has “reset” something in the shellys?

[rojer]

@juancitomadrid i see. can you downgrade to https://rojer.me/files/shelly/2.4.0-beta1/ and see if there's a difference? does it go back to disconnecting? i'd like to know for sure if it was my change or something else. because of what Supereg said here i don't want to be doing more frequently something that we're not supposed to be doing at all :)

[juancitomadrid]

Of course I can.
But I will be out until Sunday.
I’ll do

[jsiegenthaler]

I am having similar problems with my one and only Shelly1 running mongoose 2.3.1 sometimes reporting No Response.
I feel it happens more in the morning, but that may be because it is in a bathroom and I use the bathroom more in the morning.

Observed on Homebridge v1.2.3, so I downgraded to Homebridge v1.1.6
But now of course I realise that mongoose does not run through Homebridge so that should not be an issue.
I have 5 other Shelly1s on standard Shelly firmware going via Homebridge.
(My Mongoose Shelly1 is a trial to check stability and features before I change all others)

Environment:
IoT on separate 2.4GHz AccessPoint (old NetGear WNDR3700), running in bridge mode to my LAN.
LAN is 1gig LAN using cheap NetGear 4-port switch direct to my main cable-modem, WiFi access point.
WNDR5700 has 5GHz disabled, as I know Shelly1s are 2.4GHz only. 5GHz has different SSID (but is disabled).

Is there any logging I can do to help?
I do have a raspberry pi4 running 24x7 with Homebridge installed

[pivale]

so, i have a theory that our Bonjour/DNS-SD advertisements get lost sometimes and the records expire. we only advertise once during the TTL period (2 minutes).

can you try this firmware: https://rojer.me/files/shelly/2.4.0-beta2/

it has more frequent advertisements (every 20 seconds instead of every 60), hopefully enough will get through so records don't expire. @juancitomadrid can you try this one over the next few days and let me know if it's any better?

I've installed beta2 on one of my shellys to try to see the difference between them and I can't tell any difference... It still gets no response frequently.

[rojer]

@pivale what do you do to recover? close and open home app? something else?

[pivale]

@pivale what do you do to recover? close and open home app? something else?

Close/Open Home app and waiting, those are the only things I've tried. Sometimes it's quick to recover others not that much...

I will also try two things with my network. Changing channels and separating/changing 2.4ghz name to see if there is any improvement.
Will let you know about any results.

[rojer]

can you capture and post debug log from one of the devices when this happens?

[pivale]

I'll try with the beta2 and other with latest stable version. I will post them here

[juancitomadrid]

so, i have a theory that our Bonjour/DNS-SD advertisements get lost sometimes and the records expire. we only advertise once during the TTL period (2 minutes).
can you try this firmware: https://rojer.me/files/shelly/2.4.0-beta2/
it has more frequent advertisements (every 20 seconds instead of every 60), hopefully enough will get through so records don't expire. @juancitomadrid can you try this one over the next few days and let me know if it's any better?

I've installed beta2 on one of my shellys to try to see the difference between them and I can't tell any difference... It still gets no response frequently.

Same here.
But don't take my test into account because I am making changes to my network. Until I get a stable setup I think I'm not objective.

[pivale]

Hey, hope this helps.
having one working and the other not was random, it depends and I couldn't find a pattern yet

with v.2.3.1 - light 1pm - worked fine

201312850455:1603644547015838 mgos_sys_config.c:232   Loading conf2.json
201312990526 mgos_sys_config.c:174   Saved to conf9.json
201313043432 mg_rpc.c:292            Shelly.GetInfo via HTTP 192.168.1.82:61393
201320218076 shelly_main.cpp:482     Up 201320.21, HAP 0/1/9 ns 1, RAM: 22292/38912; 0.1: st:1 in_st:0 inm:0
201328227221 shelly_main.cpp:482     Up 201328.21, HAP 0/1/9 ns 1, RAM: 23640/38912; 0.1: st:1 in_st:0 inm:0
201334446599 HAPPlatformTCPStrea:120 0x3fff5cbc 192.168.1.96:57509 Incoming HAP connection, ns 0/1/9
201334461460 HAPPlatformTCPStrea:274 0x3fff5cbc 192.168.1.96:57509 Accepted HAP connection, ns 0/2/9 ts 0x3fff5c5c
201336218494 shelly_main.cpp:482     Up 201336.21, HAP 0/2/9 ns 2, RAM: 21104/38912; 0.1: st:1 in_st:0 inm:0
201344218278 shelly_main.cpp:482     Up 201344.21, HAP 0/2/9 ns 2, RAM: 22336/38912; 0.1: st:1 in_st:0 inm:0
201352218660 shelly_main.cpp:482     Up 201352.21, HAP 0/2/9 ns 2, RAM: 22336/38912; 0.1: st:1 in_st:0 inm:0
201360218088 shelly_main.cpp:482     Up 201360.21, HAP 0/2/9 ns 2, RAM: 22336/38912; 0.1: st:1 in_st:0 inm:0
201368218082 shelly_main.cpp:482     Up 201368.21, HAP 0/2/9 ns 2, RAM: 22336/38912; 0.1: st:1 in_st:0 inm:0
201376218399 shelly_main.cpp:482     Up 201376.21, HAP 0/2/9 ns 2, RAM: 22336/38912; 0.1: st:1 in_st:0 inm:0
201384218103 shelly_main.cpp:482     Up 201384.21, HAP 0/2/9 ns 2, RAM: 21636/38912; 0.1: st:1 in_st:0 inm:0
201392218014 shelly_main.cpp:482     Up 201392.21, HAP 0/2/9 ns 2, RAM: 22336/38912; 0.1: st:1 in_st:0 inm:0
201396935496 mgos_http_server.c:180  0x3fff5d74 HTTP connection from 192.168.1.82:61417

with beta2 - roller shutter 2.5 - got a "no response"

90743945073:1603644552474263 mgos_sys_config.c:232   Loading conf2.json
90744086656 mgos_sys_config.c:174   Saved to conf9.json
90744148897 mg_rpc.c:292            Shelly.GetInfo via HTTP 192.168.1.82:61402
90750426932 shelly_main.cpp:543     Up 90750.41, HAP 0/1/9 ns 1, RAM: 25032/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90758417276 shelly_main.cpp:543     Up 90758.41, HAP 0/1/9 ns 1, RAM: 24176/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90760631184 HAPPlatformTCPStrea:120 0x3fff618c 192.168.1.96:57508 Incoming HAP connection, ns 0/1/9
90760646074 HAPPlatformTCPStrea:274 0x3fff618c 192.168.1.96:57508 Accepted HAP connection, ns 0/2/9 ts 0x3fff1fac
90766417404 shelly_main.cpp:543     Up 90766.41, HAP 0/2/9 ns 2, RAM: 23656/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90774417164 shelly_main.cpp:543     Up 90774.41, HAP 0/2/9 ns 2, RAM: 23656/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90782417227 shelly_main.cpp:543     Up 90782.41, HAP 0/2/9 ns 2, RAM: 23664/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90790417388 shelly_main.cpp:543     Up 90790.41, HAP 0/2/9 ns 2, RAM: 23664/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90798417416 shelly_main.cpp:543     Up 90798.41, HAP 0/2/9 ns 2, RAM: 23664/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90806417629 shelly_main.cpp:543     Up 90806.41, HAP 0/2/9 ns 2, RAM: 23664/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90814417623 shelly_main.cpp:543     Up 90814.41, HAP 0/2/9 ns 2, RAM: 22900/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90818195307 HAPPlatformTCPStrea:104 0x3fff618c 192.168.1.96:57508 HAP connection closed, ns 0/2/9 i 2
90818208703 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff1fac nc 0x0 0/1/9
90822417313 shelly_main.cpp:543     Up 90822.41, HAP 0/1/9 ns 1, RAM: 24184/41104; st 65; 4.1: c:1 mp:157.06 mt_ms:14590 cp:34.24
90825478252 mgos_http_server.c:180  0x3fff618c HTTP connection from 192.168.1.82:61418

[jsiegenthaler]

For what it's worth, I had a No Response moment on my Shelly1 with v2.3.1

I grabbed the logs about 1 minute later, here they are:

`

93838055133 shelly_main.cpp:482 Up 93837.98, HAP 0/3/9 ns 3, RAM: 22052/38912; 0.1: st:0 in_st:1 inm:2
93838322006 mgos_sntp.c:95 SNTP query to time.google.com
93838422873 mgos_sntp.c:58 SNTP reply from 216.239.35.12: time 1603637738.486375, local 1603637738.005934, delta 0.480441
93845989661:1603637746048777 shelly_main.cpp:482 Up 93845.98, HAP 0/3/9 ns 3, RAM: 22052/38912; 0.1: st:0 in_st:1 inm:2
93853989616 shelly_main.cpp:482 Up 93853.98, HAP 0/3/9 ns 3, RAM: 22052/38912; 0.1: st:0 in_st:1 inm:2
93861989652 shelly_main.cpp:482 Up 93861.98, HAP 0/3/9 ns 3, RAM: 22056/38912; 0.1: st:0 in_st:1 inm:2
93869990023 shelly_main.cpp:482 Up 93869.98, HAP 0/3/9 ns 3, RAM: 22056/38912; 0.1: st:0 in_st:1 inm:2
93871593379 HAPPlatformTCPStrea:104 0x3fff6a04 192.168.0.176:54751 HAP connection closed, ns 0/3/9 i 2
93871606072 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff6724 nc 0x0 0/2/9
93875704813 HAPPlatformTCPStrea:104 0x3fff6584 192.168.0.144:57142 HAP connection closed, ns 0/2/9 i 2
93875717495 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff66fc nc 0x0 0/1/9
93876701294 HAPPlatformTCPStrea:120 0x3fff54b4 192.168.0.144:57145 Incoming HAP connection, ns 0/1/9
93876715376 HAPPlatformTCPStrea:274 0x3fff54b4 192.168.0.144:57145 Accepted HAP connection, ns 0/2/9 ts 0x3fff553c
93877997391 shelly_main.cpp:482 Up 93877.99, HAP 0/2/9 ns 2, RAM: 22204/38912; 0.1: st:0 in_st:1 inm:2
93885989595 shelly_main.cpp:482 Up 93885.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93893989663 shelly_main.cpp:482 Up 93893.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93901989969 shelly_main.cpp:482 Up 93901.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93909989722 shelly_main.cpp:482 Up 93909.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93917989571 shelly_main.cpp:482 Up 93917.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93925989592 shelly_main.cpp:482 Up 93925.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93933989754 shelly_main.cpp:482 Up 93933.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93941989719 shelly_main.cpp:482 Up 93941.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93949989821 shelly_main.cpp:482 Up 93949.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93950550918 HAPPlatformTCPStrea:104 0x3fff54b4 192.168.0.144:57145 HAP connection closed, ns 0/2/9 i 2
93950563607 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff553c nc 0x0 0/1/9
93957989865 shelly_main.cpp:482 Up 93957.98, HAP 0/1/9 ns 1, RAM: 23400/38912; 0.1: st:0 in_st:1 inm:2
93959524654 HAPPlatformTCPStrea:120 0x3fff5f0c 192.168.0.53:56228 Incoming HAP connection, ns 0/1/9
93959539632 HAPPlatformTCPStrea:274 0x3fff5f0c 192.168.0.53:56228 Accepted HAP connection, ns 0/2/9 ts 0x3fff60a4
93965989827 shelly_main.cpp:482 Up 93965.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93973989636 shelly_main.cpp:482 Up 93973.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93981989546 shelly_main.cpp:482 Up 93981.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93989989561 shelly_main.cpp:482 Up 93989.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93997989850 shelly_main.cpp:482 Up 93997.98, HAP 0/2/9 ns 2, RAM: 22720/38912; 0.1: st:0 in_st:1 inm:2
93999252495 HAPPlatformTCPStrea:120 0x3fff621c 192.168.0.144:57147 Incoming HAP connection, ns 0/2/9
93999297819 HAPPlatformTCPStrea:274 0x3fff621c 192.168.0.144:57147 Accepted HAP connection, ns 0/3/9 ts 0x3fff635c
94005989647 shelly_main.cpp:482 Up 94005.98, HAP 0/3/9 ns 3, RAM: 22044/38912; 0.1: st:0 in_st:1 inm:2
94013989741 shelly_main.cpp:482 Up 94013.98, HAP 0/3/9 ns 3, RAM: 22044/38912; 0.1: st:0 in_st:1 inm:2
94021989932 shelly_main.cpp:482 Up 94021.98, HAP 0/3/9 ns 3, RAM: 22044/38912; 0.1: st:0 in_st:1 inm:2
94024764338 HAPPlatformTCPStrea:120 0x3fff62a4 192.168.0.176:54754 Incoming HAP connection, ns 0/3/9
94024779431 HAPPlatformTCPStrea:274 0x3fff62a4 192.168.0.176:54754 Accepted HAP connection, ns 0/4/9 ts 0x3fff68fc
94029989951 shelly_main.cpp:482 Up 94029.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94037989929 shelly_main.cpp:482 Up 94037.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94045989879 shelly_main.cpp:482 Up 94045.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94053989594 shelly_main.cpp:482 Up 94053.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94061989672 shelly_main.cpp:482 Up 94061.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94069989612 shelly_main.cpp:482 Up 94069.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94077989592 shelly_main.cpp:482 Up 94077.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94085989909 shelly_main.cpp:482 Up 94085.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94093989608 shelly_main.cpp:482 Up 94093.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94101989687 shelly_main.cpp:482 Up 94101.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94109989632 shelly_main.cpp:482 Up 94109.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94117989980 shelly_main.cpp:482 Up 94117.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94125990328 shelly_main.cpp:482 Up 94125.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94133989611 shelly_main.cpp:482 Up 94133.98, HAP 0/4/9 ns 4, RAM: 21364/38912; 0.1: st:0 in_st:1 inm:2
94140090907 HAPPlatformTCPStrea:104 0x3fff28fc 192.168.0.89:51014 HAP connection closed, ns 0/4/9 i 2
94140133829 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff548c nc 0x0 0/3/9
94140147765 HAPPlatformTCPStrea:104 0x3fff621c 192.168.0.144:57147 HAP connection closed, ns 0/3/9 i 2
94140159506 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff635c nc 0x0 0/2/9
94140173991 HAPPlatformTCPStrea:104 0x3fff5f0c 192.168.0.53:56228 HAP connection closed, ns 0/2/9 i 2
94140185715 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff60a4 nc 0x0 0/1/9
94140200330 HAPPlatformTCPStrea:104 0x3fff62a4 192.168.0.176:54754 HAP connection closed, ns 0/1/9 i 2
94140212076 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff68fc nc 0x0 0/0/9
94141435196 esp_main.c:158 SDK: ip:192.168.0.195,mask:255.255.255.0,gw:192.168.0.1
94141451279 mgos_net.c:101 WiFi STA: ready, IP 192.168.0.195, GW 192.168.0.1, DNS 62.2.17.61
94141989796 shelly_main.cpp:482 Up 94141.98, HAP 0/0/9 ns 0, RAM: 24072/38912; 0.1: st:0 in_st:1 inm:2
94149989609 shelly_main.cpp:482 Up 94149.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94157989541 shelly_main.cpp:482 Up 94157.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94165989614 shelly_main.cpp:482 Up 94165.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94167695127 HAPPlatformTCPStrea:120 0x3fff6584 192.168.0.144:57150 Incoming HAP connection, ns 0/0/9
94167709272 HAPPlatformTCPStrea:274 0x3fff6584 192.168.0.144:57150 Accepted HAP connection, ns 0/1/9 ts 0x3fff2914
94168763277 HAPPlatformTCPStrea:104 0x3fff6584 192.168.0.144:57150 HAP connection closed, ns 0/1/9 i 2
94168775061 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff2914 nc 0x0 0/0/9
94173989625 shelly_main.cpp:482 Up 94173.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94181989593 shelly_main.cpp:482 Up 94181.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94189989612 shelly_main.cpp:482 Up 94189.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94197989622 shelly_main.cpp:482 Up 94197.98, HAP 0/0/9 ns 0, RAM: 24112/38912; 0.1: st:0 in_st:1 inm:2
94202037475 HAPPlatformTCPStrea:120 0x3fff6584 192.168.0.89:51016 Incoming HAP connection, ns 0/0/9
94202052511 HAPPlatformTCPStrea:274 0x3fff6584 192.168.0.89:51016 Accepted HAP connection, ns 0/1/9 ts 0x3fff2914
94203319468 HAPPlatformTCPStrea:120 0x3fff68fc 192.168.0.144:57151 Incoming HAP connection, ns 0/1/9
94203367903 HAPPlatformTCPStrea:120 0x3fff6bc4 192.168.0.176:54762 Incoming HAP connection, ns 1/1/9
94205989446 HAPPlatformTCPStrea:274 0x3fff68fc 192.168.0.144:57151 Accepted HAP connection, ns 1/2/9 ts 0x3fff6ad4
94207051561 shelly_main.cpp:482 Up 94207.04, HAP 1/2/9 ns 2, RAM: 21980/38912; 0.1: st:0 in_st:1 inm:2
94209051556 HAPPlatformTCPStrea:274 0x3fff6bc4 192.168.0.176:54762 Accepted HAP connection, ns 0/3/9 ts 0x3fff66fc
94210119199 HAPPlatformTCPStrea:104 0x3fff6bc4 192.168.0.176:54762 HAP connection closed, ns 0/3/9 i 2
94210131965 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff66fc nc 0x0 0/2/9
94212431342 HAPPlatformTCPStrea:120 0x3fff5e94 192.168.0.176:54764 Incoming HAP connection, ns 0/2/9
94212445524 HAPPlatformTCPStrea:274 0x3fff5e94 192.168.0.176:54764 Accepted HAP connection, ns 0/3/9 ts 0x3fff66fc
94216113339 shelly_main.cpp:482 Up 94216.10, HAP 0/3/9 ns 3, RAM: 22516/38912; 0.1: st:0 in_st:1 inm:2
94224113625 shelly_main.cpp:482 Up 94224.10, HAP 0/3/9 ns 3, RAM: 22516/38912; 0.1: st:0 in_st:1 inm:2
94230129025 mgos_http_server.c:180 0x3fff6bc4 HTTP connection from 192.168.0.149:51062
94230147340 mgos_http_server.c:187 0x3fff6bc4 GET /
94230179490 mgos_http_server.c:180 0x3fff700c HTTP connection from 192.168.0.149:51063
94230248437 mgos_http_server.c:187 0x3fff6bc4 GET /axios.min.js.gz
94230272965 mgos_http_server.c:187 0x3fff700c GET /logo.png
94230445793 mg_rpc.c:292 Shelly.GetInfo via HTTP 192.168.0.149:51063
94230471887 mgos_http_server.c:187 0x3fff6bc4 GET /favicon.ico
94232113367 shelly_main.cpp:482 Up 94232.10, HAP 0/3/9 ns 3, RAM: 21480/38912; 0.1: st:0 in_st:1 inm:2
`

[pivale]

On this one I always get no response (except for one time or another, but rarely).

523652482:1603646540155756 mgos_sys_config.c:232   Loading conf2.json
523793882 mgos_sys_config.c:174   Saved to conf9.json
523825185 shelly_main.cpp:482     Up 523.81, HAP 0/2/9 ns 2, RAM: 20240/38712; 4.1: c:1 mp:160.03 mt_ms:14889 cp:0.00
523843606 mg_rpc.c:292            Shelly.GetInfo via HTTP 192.168.1.82:62045
523864481 mgos_mongoose.c:66      New heap free LWM: 16336
531812731 shelly_main.cpp:482     Up 531.79, HAP 0/2/9 ns 2, RAM: 22648/38712; 4.1: c:1 mp:160.03 mt_ms:14889 cp:0.00
536490480 HAPPlatformTCPStrea:120 0x3fff63bc 192.168.1.68:56103 Incoming HAP connection, ns 0/2/9
536505441 HAPPlatformTCPStrea:274 0x3fff63bc 192.168.1.68:56103 Accepted HAP connection, ns 0/3/9 ts 0x3fff5814
538672546 mgos_http_server.c:180  0x3fff6c2c HTTP connection from 192.168.1.82:62059

[rojer]

can you identify the controller's ip address here? basically, i want to know what happens to its connection.

[pivale]

what do you mean the controller? The device that asked for the status?
I'm only using fixed IPs for the shellys, so now they have changed and are not being used...

I'll send new ones with IPs decoded as soon as I can replicate.

[rojer]

yes, controllers in HAP terminology are the iDevices.
no need to decode everything, i'm only interested in the fate of the connection from the device that reports "no response".
so, say you pick up your iphone, open home app and see shelly devices with "no response". wait for connection to re-establish, then capture log on shelly, post here and let me know what was the ip of the iphone at the time.

[rojer]

as a general note, i see a lot of connection churn. connection are either closed by remote side or by tcp-ip stack on the shelly device - due to failing keep-alives, most likely.
i wonder if possibly this has to do with TCP connection maintenance when iDevices are in sleep or inactive mode, maybe they are not awake enough to maintain their connections?

[pivale]

In the meanwhile, I've split 2.4 and 5ghz networks in two different SSIDs and I'm testing with it.
It seems to be a lot better, which might resonate with @andyblac 's take on this issue... Although I struggle to understand why 😛

If I can't replicate again (and problem solved) I will try to find time to revert this and retest.

[pivale]

Also, I've used NetSpot to check all wifi networks around me and adjusted the channel to more available ones.
I live in an apartment in a moderately busy street and this is CROWDED!

Also, hint, if you have multiple APs, make sure they are not using the same channels.

I'll let you know how it's working in a few days.

@andyblac maybe we could add this hints to a troubleshooting section in the wiki.

[rojer]

definitely should, assuming this solves the problem.
i can tell it's not the sleep issue, i don't see it on my devices.
unlike you, i live in a very quiet place (radio and in general) and my connections are rock solid.

[andyblac]

let me know if it helps, and I'll write up a "Trouble shooting" section.

[andyblac]

In the meanwhile, I've split 2.4 and 5ghz networks in two different SSIDs and I'm testing with it.
It seems to be a lot better, which might resonate with @andyblac 's take on this issue... Although I struggle to understand why 😛

If I can't replicate again (and problem solved) I will try to find time to revert this and retest.

the AP tries to handoff the client to 5Ghz eventhough the client can't handle it, some AP's are pretty dumb, and just assume it can, and they do check to make sure it actually got a connection, also the reverse is true, and the client just tries to connect to 5Ghz and does not report back to the AP if connection fails, Hamony Hubs are known for this issue, if you have a SSID with both 5Ghz & 2.4Ghz, and have "prefer 5Ghz" enabled on an AP, they fail to get a connection. so IMO this could be either your AP not handling it very well or it could be the mongoose wifi library it self.

For this reason i always have a SSID on purely for IoT on a 2.4Ghz, and in a seperate VLAN (but this is not necessary).

[rojer]

fwiw shellies only support 2.4 GHz, so it shouldn't be handoff issue.
that said, bridging of traffic, especially multicast, between 5 ghz and 2.4 ghz may be problematic on some APs.

[andyblac]

fwiw shellies only support 2.4 GHz, so it shouldn't be handoff issue.
that said, bridging of traffic, especially multicast, between 5 ghz and 2.4 ghz may be problematic on some APs.

so are Harmony Hubs, but it is known proven issue. they dropping off the SSID if you try to connect them on a SSID that host both 5 & 2.4Ghz

for referance only https://support.logi.com/hc/en-gb/community/posts/360032797113-Cannot-Connect-to-Harmon-Hub-via-Wifi-when-will-this-be-fixed-

[pivale]

Hey,

First of all, reworking my network seems to have helped a lot! I get a lot fewer "no response" and it's a lot quicker to recover.
Still, I get some disconnects from time to time.

Here is the log from one of them:

60194077759 mgos_sys_config.c:232   Loading conf2.json
60194105614 mgos_sys_config.c:232   Loading conf3.json
60194237000 mgos_sys_config.c:174   Saved to conf9.json
60194303329 shelly_hap_window_c:305 WC 1: State: stop -> stopping (24 -> 25)
60194318102 shelly_hap_window_c:305 WC 1: State: stopping -> idle (25 -> 0)
60194988772 shelly_input.cpp:72     Input 1: long (state 0)
60198320082 shelly_main.cpp:482     Up 60198.31, HAP 0/0/9 ns 0, RAM: 22540/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60206319998 shelly_main.cpp:482     Up 60206.31, HAP 0/0/9 ns 0, RAM: 22540/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60214319960 shelly_main.cpp:482     Up 60214.31, HAP 0/0/9 ns 0, RAM: 22540/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60222319873 shelly_main.cpp:482     Up 60222.31, HAP 0/0/9 ns 0, RAM: 22540/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60230319910 shelly_main.cpp:482     Up 60230.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60238319941 shelly_main.cpp:482     Up 60238.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60246320029 shelly_main.cpp:482     Up 60246.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60254319914 shelly_main.cpp:482     Up 60254.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60262319913 shelly_main.cpp:482     Up 60262.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60270319959 shelly_main.cpp:482     Up 60270.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60278319885 shelly_main.cpp:482     Up 60278.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60286319988 shelly_main.cpp:482     Up 60286.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60294319920 shelly_main.cpp:482     Up 60294.31, HAP 0/0/9 ns 0, RAM: 22372/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60301473946 HAPPlatformTCPStrea:120 0x3fff5b2c 192.168.1.82:53507 Incoming HAP connection, ns 0/0/9
60301488908 HAPPlatformTCPStrea:274 0x3fff5b2c 192.168.1.82:53507 Accepted HAP connection, ns 0/1/9 ts 0x3fff558c
60301601255 HAPPlatformTCPStrea:120 0x3fff629c 192.168.1.71:49507 Incoming HAP connection, ns 0/1/9
60302744620 shelly_main.cpp:482     Up 60302.73, HAP 1/1/9 ns 1, RAM: 19952/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60304541868 HAPPlatformTCPStrea:274 0x3fff629c 192.168.1.71:49507 Accepted HAP connection, ns 0/2/9 ts 0x3fff574c
60310319975 shelly_main.cpp:482     Up 60310.31, HAP 0/2/9 ns 2, RAM: 20296/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60318319957 shelly_main.cpp:482     Up 60318.31, HAP 0/2/9 ns 2, RAM: 21252/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60326319924 shelly_main.cpp:482     Up 60326.31, HAP 0/2/9 ns 2, RAM: 21252/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60334319970 shelly_main.cpp:482     Up 60334.31, HAP 0/2/9 ns 2, RAM: 21252/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60342319994 shelly_main.cpp:482     Up 60342.31, HAP 0/2/9 ns 2, RAM: 21252/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60350319915 shelly_main.cpp:482     Up 60350.31, HAP 0/2/9 ns 2, RAM: 21252/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60358319925 shelly_main.cpp:482     Up 60358.31, HAP 0/2/9 ns 2, RAM: 21252/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60361609284 HAPPlatformTCPStrea:120 0x3fff63e4 192.168.1.96:59810 Incoming HAP connection, ns 0/2/9
60361623327 HAPPlatformTCPStrea:274 0x3fff63e4 192.168.1.96:59810 Accepted HAP connection, ns 0/3/9 ts 0x3fff552c
60366319987 shelly_main.cpp:482     Up 60366.31, HAP 0/3/9 ns 3, RAM: 20732/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60374319983 shelly_main.cpp:482     Up 60374.31, HAP 0/3/9 ns 3, RAM: 20732/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60382319984 shelly_main.cpp:482     Up 60382.31, HAP 0/3/9 ns 3, RAM: 20732/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60390319989 shelly_main.cpp:482     Up 60390.31, HAP 0/3/9 ns 3, RAM: 20732/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60398320011 shelly_main.cpp:482     Up 60398.31, HAP 0/3/9 ns 3, RAM: 20732/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60398686672 mgos_http_server.c:180  0x3fff67e4 HTTP connection from 192.168.1.82:53535
60398701085 mgos_http_server.c:187  0x3fff67e4 GET /
60398724195 mg_http.c:368           '/index.html.gz' '/index.html' 'text/html'
60398983871 mgos_http_server.c:180  0x3fff6c74 HTTP connection from 192.168.1.82:53536
60399000188 mgos_http_server.c:187  0x3fff6c74 GET /axios.min.js.gz
60399039839 mgos_http_server.c:187  0x3fff6c74 GET /logo.png
60399847369 mgos_http_server.c:180  0x3fff682c HTTP connection from 192.168.1.82:53538
60400707337 mg_rpc.c:292            Shelly.GetInfo via HTTP 192.168.1.82:53538
60406329618 shelly_main.cpp:482     Up 60406.31, HAP 0/3/9 ns 3, RAM: 21520/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60408348487 mgos_http_server.c:180  0x3fff6c1c HTTP connection from 192.168.1.82:53539
60414329749 shelly_main.cpp:482     Up 60414.31, HAP 0/3/9 ns 3, RAM: 20268/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60422319978 shelly_main.cpp:482     Up 60422.31, HAP 0/3/9 ns 3, RAM: 20664/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60430320004 shelly_main.cpp:482     Up 60430.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60438043852 mgos_http_server.c:180  0x3fff6b5c HTTP connection from 192.168.1.82:53544
60438329728 shelly_main.cpp:482     Up 60438.31, HAP 0/3/9 ns 3, RAM: 18020/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60446319909 shelly_main.cpp:482     Up 60446.31, HAP 0/3/9 ns 3, RAM: 20668/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60454320064 shelly_main.cpp:482     Up 60454.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60462319906 shelly_main.cpp:482     Up 60462.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60470320036 shelly_main.cpp:482     Up 60470.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60478319974 shelly_main.cpp:482     Up 60478.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60486319934 shelly_main.cpp:482     Up 60486.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60494320042 shelly_main.cpp:482     Up 60494.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60502320076 shelly_main.cpp:482     Up 60502.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60510320065 shelly_main.cpp:482     Up 60510.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60518320024 shelly_main.cpp:482     Up 60518.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60526320035 shelly_main.cpp:482     Up 60526.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60534320033 shelly_main.cpp:482     Up 60534.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60542319936 shelly_main.cpp:482     Up 60542.31, HAP 0/3/9 ns 3, RAM: 20856/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60543993123 HAPPlatformTCPStrea:104 0x3fff63e4 192.168.1.96:59810 HAP connection closed, ns 0/3/9 i 2
60544007638 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff552c nc 0x0 0/2/9
60550320080 shelly_main.cpp:482     Up 60550.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60558319956 shelly_main.cpp:482     Up 60558.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60566320013 shelly_main.cpp:482     Up 60566.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60574319944 shelly_main.cpp:482     Up 60574.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60582320031 shelly_main.cpp:482     Up 60582.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60590320061 shelly_main.cpp:482     Up 60590.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60590756717 HAPPlatformTCPStrea:120 0x3fff5d0c 192.168.1.96:59811 Incoming HAP connection, ns 0/2/9
60590770782 HAPPlatformTCPStrea:274 0x3fff5d0c 192.168.1.96:59811 Accepted HAP connection, ns 0/3/9 ts 0x3fff5724
60591948118 HAPPlatformTCPStrea:104 0x3fff5d0c 192.168.1.96:59811 HAP connection closed, ns 0/3/9 i 2
60591959965 HAPPlatformTCPStrea:301 HAPPlatformTCPStreamClose ts 0x3fff5724 nc 0x0 0/2/9
60598319947 shelly_main.cpp:482     Up 60598.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60606320068 shelly_main.cpp:482     Up 60606.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60614320063 shelly_main.cpp:482     Up 60614.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60622320058 shelly_main.cpp:482     Up 60622.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60630320025 shelly_main.cpp:482     Up 60630.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60638320051 shelly_main.cpp:482     Up 60638.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60646320089 shelly_main.cpp:482     Up 60646.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60654320003 shelly_main.cpp:482     Up 60654.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60662320050 shelly_main.cpp:482     Up 60662.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60670319970 shelly_main.cpp:482     Up 60670.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60678319985 shelly_main.cpp:482     Up 60678.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60686320226 shelly_main.cpp:482     Up 60686.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60694320132 shelly_main.cpp:482     Up 60694.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60702319943 shelly_main.cpp:482     Up 60702.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60710320040 shelly_main.cpp:482     Up 60710.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60718320011 shelly_main.cpp:482     Up 60718.31, HAP 0/2/9 ns 2, RAM: 21376/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60721649665 HAPPlatformTCPStrea:120 0x3fff5d0c 192.168.1.96:59814 Incoming HAP connection, ns 0/2/9
60721664730 HAPPlatformTCPStrea:274 0x3fff5d0c 192.168.1.96:59814 Accepted HAP connection, ns 0/3/9 ts 0x3fff5724
60726320047 shelly_main.cpp:482     Up 60726.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60734320189 shelly_main.cpp:482     Up 60734.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60742320216 shelly_main.cpp:482     Up 60742.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60750320144 shelly_main.cpp:482     Up 60750.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60758320091 shelly_main.cpp:482     Up 60758.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60766320149 shelly_main.cpp:482     Up 60766.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60774320077 shelly_main.cpp:482     Up 60774.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60782320050 shelly_main.cpp:482     Up 60782.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60790320026 shelly_main.cpp:482     Up 60790.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60798320086 shelly_main.cpp:482     Up 60798.31, HAP 0/3/9 ns 3, RAM: 20700/38712; 4.1: c:1 mp:157.53 mt_ms:14889 cp:20.22
60800818256 mgos_http_server.c:180  0x3fff75ec HTTP connection from 192.168.1.82:53678

Controller IP is 192.168.1.96 (iPhone XR with iOS14.1)
IP 192.168.1.82 is my macbook and those are the connections to retrieve the log

[rojer]

@pivale thanks!

1.96 definitely shows weird behavior.

60361609284 HAPPlatformTCPStrea:120 0x3fff63e4 192.168.1.96:59810 Incoming HAP connection, ns 0/2/9
60361623327 HAPPlatformTCPStrea:274 0x3fff63e4 192.168.1.96:59810 Accepted HAP connection, ns 0/3/9 ts 0x3fff552c
60543993123 HAPPlatformTCPStrea:104 0x3fff63e4 192.168.1.96:59810 HAP connection closed, ns 0/3/9 i 2

connection was up for 3 minutes, then terminated

60590756717 HAPPlatformTCPStrea:120 0x3fff5d0c 192.168.1.96:59811 Incoming HAP connection, ns 0/2/9
60590770782 HAPPlatformTCPStrea:274 0x3fff5d0c 192.168.1.96:59811 Accepted HAP connection, ns 0/3/9 ts 0x3fff5724
60591948118 HAPPlatformTCPStrea:104 0x3fff5d0c 192.168.1.96:59811 HAP connection closed, ns 0/3/9 i 2

that's just 1.1 second, down immediately. changed its mind? didn't like something it got back from us?
i suspect this is where the devices went into "no response" in the app.

60721649665 HAPPlatformTCPStrea:120 0x3fff5d0c 192.168.1.96:59814 Incoming HAP connection, ns 0/2/9
60721664730 HAPPlatformTCPStrea:274 0x3fff5d0c 192.168.1.96:59814 Accepted HAP connection, ns 0/3/9 ts 0x3fff5724

connection re-established and this time it sticks.

in any case, it's clear that we need more debugging information... let me think about it.

[75TiagoMatias]

I have exactly the same problem. I just close the HomeApp and open again and it is solved. But every first time I open the app, I get a "No Response" error as well..
If I can help with some debug, let me know.
Cheers!

[juancitomadrid]

Just to say that my problem was on my network.
I have fixed the disconnect and "not responding" issues when connected to another AP.
I have been a bit dramatic with the solution, but now I am very happy with the result.

I have replaced my switch with a managed one (unifi).
I have completely reconfigured my network from scratch.
Now I have two networks (one exclusive for IoT that only works at 2Ghz).
All shellys work perfectly.
The script finds them all.
thanks @rojer and @andyblac for your help.

If you need something to test... just let me know!

[andyblac]

Just to say that my problem was on my network.
I have fixed the disconnect and "not responding" issues when connected to another AP.
I have been a bit dramatic with the solution, but now I am very happy with the result.

I have replaced my switch with a managed one (unifi).
I have completely reconfigured my network from scratch.
Now I have two networks (one exclusive for IoT that only works at 2Ghz).
All shellys work perfectly.
The script finds them all.
thanks @rojer and @andyblac for your help.

If you need something to test... just let me know!

glad you sorted it, imo most issues are down to cheapo network switches.

[rojer]

@andyblac can we distill this knowledge into a troubleshooting wiki, perhaps?

[andyblac]

@andyblac can we distill this knowledge into a troubleshooting wiki, perhaps?

i can put up some 'tips' that may some help people, but imo the issue was fundentslly fixed due to him upgrading his dump switch to a managed one, when using multple AP's. Networks are complex things and without someway to control it, it never going to be working 100% for everything.

[rojer]

yeah, but we can at least say "if you experience device unavailability in the home app, try separating SSIDs, could be a switch as well.." - everything we discussed here. you can even link to this issue.

[pivale]

@andyblac I can review it and add some clarification if you want the help 😄

[andyblac]

@andyblac I can review it and add some clarification if you want the help 😄

maybe you start write up what issues you had, and what you did, i can add any additional info that i think could be helpful.

[pivale]

I'm still having some trouble, although it might be that my network equipment is at fault...

Also, I've installed an old powerline access point I had here (tp-link tp-wpa2220) to improve connectivity where it was worst, but none of the shellys is connecting there! I can connect with our home devices (iphone, ipad, macbook) but the shellys don't connect at all, although the signal is the strongest and the SSID is the same... Even after a reboot.

Any thoughts on this? Any suggestions on how to proceed?

[Marcusyo]

Im currently using the beta with the shortened response time and I think that its gotten better for me without using an HP, Apple TV or Ipad. Is it possible to add an feature for setting an custom response time? Think in the beta it got reduced from 60 to 20 seconds. Already good but for me i would like to have 2-5 seconds response time if its possible to implement.

[juancitomadrid]

Im currently using the beta with the shortened response time and I think that its gotten better for me without using an HP, Apple TV or Ipad. Is it possible to add an feature for setting an custom response time? Think in the beta it got reduced from 60 to 20 seconds. Already good but for me i would like to have 2-5 seconds response time if its possible to implement.

IMO
And because something similar has happened to me, the problem is not in the firmware, it is in the network.
I had problems of "delays" and "disconnection", I changed the configuration of my network and everything goes smoothly (same firmware as in the previous network)

[socialsubs]

IMO
And because something similar has happened to me, the problem is not in the firmware, it is in the network.
I had problems of "delays" and "disconnection", I changed the configuration of my network and everything goes smoothly (same firmware as in the previous network)

I agree with you. I have an ecobee smart thermostat (HomeKit) that was showing the same issues before I fine tuned the network configuration.

[andyblac]

I think we can close this now ? as it is not firmware related ?

[pivale]

yeah, I think you can close it, since it appears not to be firmware related...

but I would still appreciate thoughts from all of you on this... I'm puzzled and don't know what else to do!

I'm still having some trouble, although it might be that my network equipment is at fault...

Also, I've installed an old powerline access point I had here (tp-link tp-wpa2220) to improve connectivity where it was worst, but none of the shellys is connecting there! I can connect with our home devices (iphone, ipad, macbook) but the shellys don't connect at all, although the signal is the strongest and the SSID is the same... Even after a reboot.

Any thoughts on this? Any suggestions on how to proceed?

[juancitomadrid]

yeah, I think you can close it, since it appears not to be firmware related...

but I would still appreciate thoughts from all of you on this... I'm puzzled and don't know what else to do!

@pivale I`ll tell you everything I have done and what I have read that can cause this type of problems, to see if they help.

Switch
To discard a switch problem, plug the ap directly into the router and see if the problem continues.

SSID
Same for both (5ghz and 2ghz)

2GHz only wifi
Try with a only 2GHz network

Multicast ENABLE

mDNS
If you have to networks you must enable mDNS on your network settings

Anyway
I have tried everything and still had problems.
I fixed it when I went back to the factory settings on all my APs and router, and started configuring everything from scratch.

Hope this help.

[socialsubs]

@pivale I`ll tell you everything I have done and what I have read that can cause this type of problems, to see if they help.

Switch
To discard a switch problem, plug the ap directly into the router and see if the problem continues.

SSID
Same for both (5ghz and 2ghz)

2GHz only wifi
Try with a only 2GHz network

Multicast ENABLE

mDNS
If you have to networks you must enable mDNS on your network settings

Anyway
I have tried everything and still had problems.
I fixed it when I went back to the factory settings on all my APs and router, and started configuring everything from scratch.

Hope this help.

I've a mesh Wi-Fi network and I solved by setting a fixed Wi-Fi channel.

[andyblac]

@pivale I`ll tell you everything I have done and what I have read that can cause this type of problems, to see if they help.
Switch
To discard a switch problem, plug the ap directly into the router and see if the problem continues.
SSID
Same for both (5ghz and 2ghz)
2GHz only wifi
Try with a only 2GHz network
Multicast ENABLE
mDNS
If you have to networks you must enable mDNS on your network settings
Anyway
I have tried everything and still had problems.
I fixed it when I went back to the factory settings on all my APs and router, and started configuring everything from scratch.
Hope this help.

I've a mesh Wi-Fi network and I solved by setting a fixed Wi-Fi channel.

can you add this to wiki.

[d4rkmen]

Reporting here my experience: one esp device works fine. Adding another one cause mDNS “flapping” which is the reason of lost discovery and “communication problems” in paired esp
Also it refuse to pair unpaired esp

[pivale]

yeah, I think you can close it, since it appears not to be firmware related...

but I would still appreciate thoughts from all of you on this... I'm puzzled and don't know what else to do!

I'm still having some trouble, although it might be that my network equipment is at fault...
Also, I've installed an old powerline access point I had here (tp-link tp-wpa2220) to improve connectivity where it was worst, but none of the shellys is connecting there! I can connect with our home devices (iphone, ipad, macbook) but the shellys don't connect at all, although the signal is the strongest and the SSID is the same... Even after a reboot.
Any thoughts on this? Any suggestions on how to proceed?

Got it to work.
Not sure why, but it would not connect to the strongest one, it rather keeps the current one (maybe by mac address of the AP?).
I switched off momentarily the weakest AP, the shellys connected to the powerline AP and now they are all good.

I seldom see disconnects now.
I might need to revamp my whole network, but it's not a something I will work on on the short term.
Thank you all for the suggestions

[andyblac]

yeah, I think you can close it, since it appears not to be firmware related...
but I would still appreciate thoughts from all of you on this... I'm puzzled and don't know what else to do!

I'm still having some trouble, although it might be that my network equipment is at fault...
Also, I've installed an old powerline access point I had here (tp-link tp-wpa2220) to improve connectivity where it was worst, but none of the shellys is connecting there! I can connect with our home devices (iphone, ipad, macbook) but the shellys don't connect at all, although the signal is the strongest and the SSID is the same... Even after a reboot.
Any thoughts on this? Any suggestions on how to proceed?

Got it to work.
Not sure why, but it would not connect to the strongest one, it rather keeps the current one (maybe by mac address of the AP?).
I switched off momentarily the weakest AP, the shellys connected to the powerline AP and now they are all good.

I seldom see disconnects now.
I might need to revamp my whole network, but it's not a something I will work on on the short term.
Thank you all for the suggestions

if you have RSSI control in the your AP's it might be worth playing around with it, i have an AP in every room of the house, and as thus i had to tune the RSSI's to stop 'hopping' of the clients between AP's

[juancitomadrid]

if you have RSSI control in the your AP's it might be worth playing around with it, i have an AP in every room of the house, and as thus i had to tune the RSSI's to stop 'hopping' of the clients between AP's

@andyblac Could you tell us what specifications you have put on each APs?
Unifi controller no longer allows to change the ssid to each AP, and some of my devices connect to a distant ap instead of the closest one.

[juancitomadrid]

@pivale I`ll tell you everything I have done and what I have read that can cause this type of problems, to see if they help.
Switch
To discard a switch problem, plug the ap directly into the router and see if the problem continues.
SSID
Same for both (5ghz and 2ghz)
2GHz only wifi
Try with a only 2GHz network
Multicast ENABLE
mDNS
If you have to networks you must enable mDNS on your network settings
Anyway
I have tried everything and still had problems.
I fixed it when I went back to the factory settings on all my APs and router, and started configuring everything from scratch.
Hope this help.

I've a mesh Wi-Fi network and I solved by setting a fixed Wi-Fi channel.

can you add this to wiki.

of course.

Edited: I just saw that @pivale has done it! Thanks.

[andyblac]

if you have RSSI control in the your AP's it might be worth playing around with it, i have an AP in every room of the house, and as thus i had to tune the RSSI's to stop 'hopping' of the clients between AP's

@andyblac Could you tell us what specifications you have put on each APs?
Unifi controller no longer allows to change the ssid to each AP, and some of my devices connect to a distant ap instead of the closest one.

all my AP's have the same SSID for 2.4Ghz i am talking about RSSI.

as you can see, i have the power set to medium and RSSI to -75db, so if your furthest AP's is higher than xx you canget it to refuse the connection.

[juancitomadrid]

all my AP's have the same SSID for 2.4Ghz i am talking about RSSI.

as you can see, i have the power set to medium and RSSI to -75db

Perfect!
I have it exactly the same configuration.
The only thing I didn't have was the minimum of RSSI enable. I Will try.
Thanks!

[andyblac]

Perfect!
I have it exactly the same configuration.
The only thing I didn't have was the minimum of RSSI enable. I Will try.
Thanks!

take a look at your client list and the their RSSI's to get an idea what signal strength is on each AP', you'll need to pay around, take a little while to get tuned correctly.

[andyblac]

here what i have

[rojer]

@d4rkmen those are different devices, looks like one is paired and one is not:

$ grep :42 q
c#=1 ff=0 id=3A:97:BC:EA:3D:42 md=MEL-AC pv=1.1 s#=1 sf=1 ci=21
c#=1 ff=0 id=3A:97:BC:EA:3D:42 md=MEL-AC pv=1.1 s#=1 sf=1 ci=21
c#=1 ff=0 id=3A:97:BC:EA:3D:42 md=MEL-AC pv=1.1 s#=1 sf=1 ci=21
c#=1 ff=0 id=3A:97:BC:EA:3D:42 md=MEL-AC pv=1.1 s#=1 sf=1 ci=21
c#=1 ff=0 id=3A:97:BC:EA:3D:42 md=MEL-AC pv=1.1 s#=1 sf=1 ci=21
c#=1 ff=0 id=3A:97:BC:EA:3D:42 md=MEL-AC pv=1.1 s#=1 sf=1 ci=21
$ grep :F9 q
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21
c#=1 ff=0 id=5A:C3:E4:46:DF:F9 md=MEL-AC pv=1.1 s#=1 sf=0 ci=21

[rojer]

Not sure why, but it would not connect to the strongest one, it rather keeps the current one (maybe by mac address of the AP?).

this is known behavior of esp8266 - when looking for AP to connect to, it will connect to the first matchin AP it finds, it won't wait for more scan results to possibly find one with better signal. the first AP with matching SSID wins.
unfortunately, we have no control over that behavior...

[andyblac]

Not sure why, but it would not connect to the strongest one, it rather keeps the current one (maybe by mac address of the AP?).

this is known behavior of esp8266 - when looking for AP to connect to, it will connect to the first matchin AP it finds, it won't wait for more scan results to possibly find one with better signal. the first AP with matching SSID wins.
unfortunately, we have no control over that behavior...

yeah, which is why i use RSSI to best handle this. But it does require the AP's to support RSSI control.

[andyblac]

@pivale this still an issue ?, or can i close ticket ?

[pivale]

All seems to be working fine now.
This was a networking problem. All the findings were documented here:
https://github.com/mongoose-os-apps/shelly-homekit/wiki/Trouble-Shooting

[d4rkmen]

It's not resolved so far, due to other nature of the problem
From time to time in real life with multiple HAP accessories running it's reproducing easy

https://github.com/apple/HomeKitADK/issues/75

[andyblac]

@rojer do you think it is a firmware issue on this project or issue elsewhere ?
like this https://github.com/mongoose-os-apps/shelly-homekit/issues/129