Please greyout SSDP option until bug is solved

[Domosapiens]

Version mega-20181101 normal 4096
Ref #1573 (14 Juli)
Ref #1330 (April 29!!!)

When enabling SSDP the unit goes into a bootloop.
This happens to the 2# units I tried.

Serial port Reset is the only way to stop it.
After Reset there is a strange mix of fixed IP (in GUI) and dynamic IP (connection behavior)
So secondary, I think the Reset function is not up-to-date.
A blank file is the only real solution (I guess)

Don't know if this is related to the current WiFi problems.
If not, I can imagine that this bug has no priority.

But ... please greyout the SSDP option for the time being.

Catch from the serial:
=============Exception (28) =========================
`INIT : Booting version: mega-20181101 (ESP82xx Core 00000000, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
96 : INIT : Warm boot #216 - Restart Reason: Exception
98 : FS : Mounting...
123 : FS : Mount successful, used 78563 bytes of 957314
474 : CRC : program checksum ...OK
511 : CRC : SecuritySettings CRC ...OK
589 : INIT : Free RAM:29000
590 : INIT : I2C
590 : INIT : SPI not enabled
594 : INIT : Pulse 12
3345 : INFO : Plugins: 46 [Normal] (ESP82xx Core 00000000, NONOS SDK 2.2.1(cfd48f3), LWIP: 2.0.3)
3347 : EVENT: System#Wake
3433 : WIFI : Set WiFi to STA
3465 : WIFI : Connecting POWLAN_R2 attempt #0
3466 : IP : Static IP : 192.168.1.91 GW: 192.168.1.1 SN: 255.255.255.0 DNS: 192.168.1.1
3479 : EVENT: System#Boot
3540 : EVENT: Flow#Count=0.00
3593 : EVENT: Flow#Total=0.00
3646 : EVENT: Flow#Time=0.00
3696 : Domoticz: Sensortype: 1 idx: 109 values: 0.0
3878 : SYS : 100.00
3880 : EVENT: Load#MUC21_Load=100.00
3944 : Domoticz: Sensortype: 1 idx: 110 values: 100
3976 : DS : Temperature: 20.37 (28-da-30-1-0-0-80-92)
3982 : EVENT: TempH#TemperatureH=20.37
4103 : ACT : TaskValueSet 12,1,1
4156 : Domoticz: Sensortype: 1 idx: 106 values: 20.4
4162 : Command: taskvalueset
4213 : DS : Temperature: 20.25 (28-ff-7c-68-a2-16-3-95)
4216 : EVENT: TempL#TemperatureL=20.25
4349 : ACT : TaskValueSet 7,1, 20.4-20.3
4365 : ACT : TaskValueSet 12,1,0
4417 : Domoticz: Sensortype: 1 idx: 107 values: 20.3
4589 : Dummy: value 1: 0.00
4589 : Dummy: value 2: 0.00
4589 : Dummy: value 3: 0.00
4590 : Dummy: value 4: 0.00
4595 : EVENT: DeltaT#Delta_T=0.00
4663 : ACT : TaskvalueSet 7,2, 0.0*-102+1122
4701 : EVENT: DeltaT#Delta_T_PWM=0.00
4817 : ACT : TaskvalueSet 7,3, 3
4945 : EVENT: DeltaT#Pin_PWM=0.00
5004 : ACT : PWM,13, 300

Exception (28):
epc1=0x4020c3f9 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000

ctx: cont
sp: 3ffffcd0 end: 3fffffd0 offset: 01a0

stack>>>
3ffffe70: 3ffffe70 3ffffe70 3ffffe78 3ffffe78
3ffffe80: 3ffffe80 3ffffe80 3ffffe88 3ffffe88
3ffffe90: 3ffffe90 3ffffe90 3ffffe98 3ffffe98
3ffffea0: 3ffffea0 3ffffea0 3ffffea8 3ffffea8
3ffffeb0: 3ffffeb0 3ffffeb0 3ffffeb8 3ffffeb8
3ffffec0: 3ffffec0 3ffffec0 3ffffec8 3ffffec8
3ffffed0: 3ffffed0 3fff19ea 3ffffed8 3ffffed8
3ffffee0: 3ffffee0 3ffffee0 00000010 401004e8
3ffffef0: 00000000 4021f826 00000010 402190e7
3fffff00: 0000882f 3fff1788 3fff4260 4021f85c
3fffff10: 0000000b 3fff19b0 0000019c 4010020c
3fffff20: 00563d4f 3fffff50 0000882f 3fff28bc
3fffff30: 3fffdad0 00000001 3ffea52c 3fff28bc
3fffff40: 3fffdad0 3fff19ea 3fff1754 4024a914
3fffff50: 0000882f 3fff28bc 4025d884 3fffefb0
3fffff60: 3fffdad0 00000001 3ffea52c 40258d2d
3fffff70: 3fffdad0 00000001 00000004 40258de4
3fffff80: 000012ff 00000000 3fff15e0 402194f7
3fffff90: 3fffdad0 00000000 3fff15e0 40258e9d
3fffffa0: 00000000 00000000 00000001 4025d8a5
3fffffb0: 3fffdad0 00000000 3fff28b2 4025d914
3fffffc0: feefeffe feefeffe 3ffe87b8 40100721
<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v00000000
~ld
ªU96 :
`

[TD-er]

That's a good feature I guess.
Or maybe we should even hide the option as long as it isn't working.

[Domosapiens]

@TD-er
Greyout is more clear for those who are searching for this good working feature from the 2017 releases ;)
(but much slower!)

[uzi18]

@TD-er @Grovkillen maybe it is a good idea to compare some timings from old ESPEasy to actual development version ?? :)

[TD-er]

@uzi18 What timings do you mean?

[uzi18]

something that will give us (new users) clue about performance of new and old firmware

[uzi18]

• rules reaction time for switch ... old/new

[TD-er]

Should be disabled with PR #2069

[mneuron]

A shame the SSDP option is not working anymore. Any idea of the cause? I really liked it.
Could it be fixed anytime soon?
Thanx

[TD-er]

I never used it myself, so I don't know what is the real problem here.
I have seen this in a few issues/patches on the core library, so it might be it has already been fixed.

Edit:
I can find only issues with 'SSDP' which are labeled "closed" So maybe it is indeed fixed. (or just a problem in our code)

[mneuron]

No the bug itself is not fixed. The webpage has the checkbox disabled, the code is still there.
Ssdp gives an icon in the windows network neighbourhood.

[TD-er]

I know about the grey checkbox (added the disabled flag myself), but I was wondering if you maybe did test to see if the functionality may have been fixed by manually enabling the option again.

[mneuron]

I tested the function by setting DEFAULT_USE_SSDP true.
Selectively disabling SSDP_update in webserver.ino wil not cause a reset loop. This suggests the bug in in SSDP_update function or in SSDP_send. (the function SSDP_schema works).
In R93 (somewhere in 2016) with almost exactly the same code works without a reset loop.

[TD-er]

That old code does not run with newer core libraries, so it must then be tested with a different core library.
And given not much has changed to that code recently, I expect these crashes (if still present) will be caused by changes in the core libraries.

[mneuron]

With trail-and-error I build a working 'preliminary' version. As I'm not a programmer and have very very limited knowledge of C, I used the library/code from esp8266/Arduino#2283 (comment) by Pawel Dino. I made some modifications in webserver.ino / espeasy.ino.
I don't have any experience in github pull requests and i think the code needs cleaning so below I pasted the modifications I made to the source.
webserver.ino:

#if defined(ESP8266)
  if (Settings.UseSSDP)
  {
    WebServer.on(F("/ssdp.xml"), HTTP_GET, []() {
      WiFiClient client(WebServer.client());
      SSDPDevice.schema(client);
    });
    SSDPDevice.setName("SSDP Test");   // change this later to resemble the unit name
    SSDPDevice.setDeviceType("urn:schemas-upnp-org:device:BinaryLight:1");
    SSDPDevice.setSchemaURL("ssdp.xml");
    SSDPDevice.setSerialNumber(ESP.getChipId());
    SSDPDevice.setURL("/");
    SSDPDevice.setModelName("ESP8266 Home Control");
    SSDPDevice.setModelNumber("ESP8266");
    SSDPDevice.setManufacturer("Home Control");
  }

In espeasy.ino add

#include <SSDPDevice.h>

and in the function runeach30second remove the sspd_update() call with a call to SSDPDevice.handleClient(); in loop(). I will test later if this function can be place in run50TimesPerSecond. If the handleClient call isn't made frequently then the icon dissapears from the network neigborhood.

I had to add some defines to SSDPDevice.cpp:

#define pip41(ipaddr) ((u16_t)(((u8_t*)(ipaddr))[0]))
#define pip42(ipaddr) ((u16_t)(((u8_t*)(ipaddr))[1]))
#define pip43(ipaddr) ((u16_t)(((u8_t*)(ipaddr))[2]))
#define pip44(ipaddr) ((u16_t)(((u8_t*)(ipaddr))[3]))


#define LIP2STR(ipaddr) pip41(ipaddr), \
    pip42(ipaddr), \
    pip43(ipaddr), \
    pip44(ipaddr)

Maybe it's possible to look at the code/modifications and see at what point it differs from the original - this causes no reset so I'm happy with it.

[TD-er]

If you put it in the 50/sec function (or anywhere else), please also do a compare to see how much time it needs.
See the timing stats page under tools. (each time you call that page it will reset the stats)

[mneuron]

In runOncePerSecond() it still functions but it seems this the max and avg duration is long compared to the 10p/s and 50p/s calls (in runEach30Seconds it 'fails';when you hit F5 in explorer it only appears after a while).
@TD-er , what would be the best place for the call?

For comparison:

handleClient in main loop:

Description	Function	#calls	call/sec	min (ms)	Avg (ms)	max (ms)
Loop		18188	5198.06	0.163	0.184	225.698
Plugin call 50 p/s		165	47.16	0.092	0.108	0.189
Plugin call 10 p/s		34	9.72	0.096	0.101	0.123
Plugin call 10 p/s U		34	9.72	0.073	0.080	0.095
Plugin call 1 p/s		3	0.86	0.213	0.224	0.244
setNewTimerAt()		236	67.45	0.101	0.112	0.198
WiFi.isConnected()		18222	5207.77	0.004	0.019	0.067
backgroundtasks()		36139	10328.38	0.017	0.030	222.551
handle_schedule() idle		17951	5130.32	0.068	0.071	9.333
handle_schedule() task		236	67.45	0.186	0.291	1.512

handleClient in run50TimesPerSecond()

Description	Function	#calls	call/sec	min (ms)	Avg (ms)	max (ms)
Loop		17680	5972.97	0.141	0.159	216.211
Plugin call 50 p/s		139	46.96	0.114	0.137	0.377
Plugin call 10 p/s		28	9.46	0.102	0.109	0.118
Plugin call 10 p/s U		28	9.46	0.074	0.076	0.096
Plugin call 1 p/s		3	1.01	0.191	0.228	0.251
setNewTimerAt()		198	66.89	0.100	0.109	0.190
WiFi.isConnected()		17708	5982.43	0.004	0.015	0.060
backgroundtasks()		35162	11879.05	0.017	0.028	215.096
handle_schedule() idle		17482	5906.08	0.068	0.069	1.777
handle_schedule() task		198	66.89	0.191	0.307	0.726

handleClient in run10TimesPerSecond() still works with

Description	Function	#calls	call/sec	min (ms)	Avg (ms)	max (ms)
Loop		19611	5536.70	0.152	0.173	228.119
Plugin call 50 p/s		167	47.15	0.103	0.111	0.166
Plugin call 10 p/s		35	9.88	0.124	0.880	1.605
Plugin call 10 p/s U		35	9.88	0.077	0.102	0.128
Plugin call 1 p/s		3	0.85	0.226	0.249	0.272
setNewTimerAt()		240	67.76	0.100	0.115	0.198
WiFi.isConnected()		19646	5546.58	0.004	0.019	0.067
backgroundtasks()		38981	11005.36	0.017	0.030	226.758
handle_schedule() idle		19370	5468.66	0.071	0.074	9.723
handle_schedule() task		240	67.76	0.201	0.432	2.973

handleClient in runOncePerSecond() also still works.

Description	Function	#calls	call/sec	min (ms)	Avg (ms)	max (ms)
Loop		10802	5938.43	0.133	0.161	223.335
Plugin call 50 p/s		81	44.53	0.097	0.113	0.185
Plugin call 10 p/s		18	9.90	0.136	0.161	0.239
Plugin call 10 p/s U		18	9.90	0.080	0.087	0.097
Plugin call 1 p/s		2	1.10	0.380	0.504	0.628
setNewTimerAt()		119	65.42	0.101	0.113	0.191
WiFi.isConnected()		10820	5948.32	0.004	0.019	0.063
backgroundtasks()		21485	11811.43	0.019	0.035	222.178
handle_schedule() idle		10683	5873.01	0.054	0.057	9.409
handle_schedule() task		119	65.42	0.182	0.300	0.847

[TD-er]

It looks like it only adds some sub-msec time to the loops, so that's fine.
I guess 10/sec is fine then.