patience4711 / read-APSystems-YC600-QS1-DS3

Software for an esp8266 nodemcu to read data from APS inverters.
130 stars 24 forks source link

new version v9_11 #104

Closed patience4711 closed 1 year ago

patience4711 commented 1 year ago

The last "state of the art" now is v9_11

This version has an improved ram usage that resulted in some more free heap. It has a temporary feature to monitor free heap via mqtt. At every healthcheck a message is send to the sendtopic (with the trailing slash this is "sendtopic/heap") containing free heap. The format = {"idx":123,"nvalue":0,"svalue":"stack;heap"}. If you want to setup a sensor in domoticz for the heap, you can edit the idx in console (10;domidx=123). This is not remembered so after a reboot you have to do this again.

Furthermore there are some cosmetic changes. The details page is changed to dynamic, the data are now retieved via a request and the processing is done by the browser. Also the refreshrate of the pages is enlarged, resulting in less cpu. All and all i have a stable higher free heap and I also believe that the problem of crashing zigbee module is solved now.

swbouman commented 1 year ago

@patience4711 thank you so much for your effort!

this version looks more stable again. Free heap is at 18000 after 2 days.

Today I experienced strange behavior of the esp. I opened the web interface in edge memory dropped from 18000 till reboot in 10 secs. Only page opened was the info page.

I just discovered this behavior in edge. In safari on mobile and desktop the system staid stable.

Just to mention.

patience4711 commented 1 year ago

@swbouman I wonder how you can see the memory drop in 10 secs. What do you use to measure that?

swbouman commented 1 year ago

@patience4711 just refreshing the page every 2 secs.

I opened the info page first time to check the heap and discovered a heap of just 10000 then I refreshed the page and saw a drop to 8000 then I refreshed again and saw a heap of 7000 etc.

Normally the heap will drop just 200 bytes.

Afterwards I left edge open en watched the esp. It was blinking every 10 secs (reconnect 3 times blue led).

After closing the edge page the esp went to normal behavior.

frtz13 commented 1 year ago

running 9_8b for a couple of days, without any connection to the web UI. 2 x YC600 heap memory image

patience4711 commented 1 year ago

@swbouman So basically you say "when i want it to crash, it crashes". Well anyway i can't reproduce it.

In the mean time i implemented the suggestions made by @fwolfst and that yielded in some 2500 more free heap.

I also made the stacksize log-able by sending that via mqtt {"idx":901,"nvalue":0,"svalue":"272;25248"} nvalue=stacksize and svalue the free heap. Also visible in the infopage.

@frtz13 It seems that the heap is shrinking at every midnight, maybe by the messages written in the log. In this new experimental version i skipped the forced zigbee reset at midnight, it seems not needed anymore. Maybe we should reset the ESP insteat. 😃

here it is, v9_9a

swbouman commented 1 year ago

@patience4711 thanks for the new version. Good work!

About wanting to let the ecu crash…. No. I saw free heap on first loading info page at 10000. I thought it was a wrong value so I refreshed the page and saw a drop of 2000.

After seeing the ecu crash/reboot I left the page open in Edge and went to the Ecu. There I saw the blue led blinking every 10 secs or so.

Not a very big problem since I’m not using edge all the time, just a remark. I’m glad it is not reproducible by other members here.

I really like your work. I trie to get my brother in law in action here. He’s a master in c# programming.

Don’t expect a very soon answer, because he’s a busy man.

Thanks again 😃

patience4711 commented 1 year ago

@swbouman the blue led is blinking when the coordinator is initializing. Strange, as this implies that the zigbee was also down. Normally it would stay up when the ESP resets. So what happened here? Must be something that pulled the resetpin of the zigbee down. A brownout maybe or ... i guess we'll never know. It can't be browser related.

Btw, what is your free Stack? Mine =272 which seems not much to me. But it never varies so this won't help much i think.

frtz13 commented 1 year ago

@patience4711 installed the v9_9a. is there a special reason why the way to send the free stack/heap values changed? it now looks like: {"idx":123,"nvalue":0,"svalue":"27168;2720"} why not make some sort of json structure for sysinfo which could look like: {"uptime":809849,"version":"XXXXXX","free_heap":19384,"free_stack":2800,"current_errorCode":11,"resetCounter":0,"rssi":-57,"ip":"192.168.54.182","mac":"xx:xx:xx:xx:xx:xx"}

patience4711 commented 1 year ago

Yes, with domotics it only works that way. This is a temporary feature, should help to find a memory leak (if there is one) and than it is obsolete and will be removed. No plans to expand this as you suggest.

frtz13 commented 1 year ago

v9_9a free heap and stack after a day. no connections to web UI. 2 x YC600. image image

fwolfst commented 1 year ago

@frtz13 I assume you are located somewhere in europe and your sun-cycle is correctly in sync with your graph (== the heap also is consumed at night when there is no sun hence no polling)?

frtz13 commented 1 year ago

@fwolfst yes, I'm located in France. no polling at night, but still MQTT communication. The ECU reconnected to the MQTT broker a couple of times. Maybe some interference on the 2.4GHz band, the signal is not very strong.

patience4711 commented 1 year ago

@frtz13 in the short term there is a downward trend. The mosquitto activity at night is the heap transmission which is triggered by the healthcheck.

The pubsub client has for long been suspicious to me but I can't put my finger on it. It normally seems to work fine but once i saw a kind of loop where the esp constantly was trying to connect to mosquitto. So there is something about it. In my case mosquitto is reconnecting when the coordinator is starting. The connection seems to time-out then. Maybe a keep-alive setting or so. When i find the time i'l dive into this.

frtz13 commented 1 year ago

this morning significant decrease in stack memory. At that time there were no disconnections/reconnections to the MQTT broker. still no connections made to the web UI. image image

patience4711 commented 1 year ago

@frtz13 I am experimenting with that stack variable but i don't get valuable results. I stays stable so i wonder wat it's worth. If it didn't crash, its oke i guess.

swbouman commented 1 year ago

Uptime: 2 days, 8 hours. Free stack: 304 bytes Free heap: 19480 bytes.

Very stable. But still the problem with a restart after closing the console by pressing done.

frtz13 commented 1 year ago

free heap and stack seem to stabilize. still no connections made to web GUI. image image

patience4711 commented 1 year ago

I made some additional changes. The detailspage is now dynamic and does not use the string sendPage anymore. This should provide more free heap and less cpu as this is transfered to the browser. I also made the refreshtime of the frontpage longer, so that there is less wifi trafic and less cpu needed. By using an already existing server request i also got a little programspace. A also changed the mqtt connection method (now non-blocking) and added a tell-tale when mqtt is not connected where is should be ( 2 short flashes of the bleu led every 5 secs

Who wants to test v9_10

frtz13 commented 1 year ago

installed v. 9_10. reported free stack values reported via MQTT are weird: got a value of 120 B, then 104 B. The values are different of the value shown on the INFO page. free heap values look familiar.

patience4711 commented 1 year ago

@frtz13 I get different values too, both are the same String( stack_size() ) but this function is called at different situations so they should differ. If you go to the console and type 10;health (diag must be 1) you can see what message is send. In my case it is "we publish heap to domoticz, mess is : {"idx":901,"nvalue":0,"svalue":"23096;136"}"and that looks oke to me. I wouldn't worry about that, this figure is not significant.

patience4711 commented 1 year ago

I tinkered with the engine a bit, resulting in even more free heap. Furthermore some imperfections now improved.

I tested this myself and it worked rockstable for some days.

v9-11

swbouman commented 1 year ago

Hello @patience4711 ,

you deleted my post about the crash of v9.11 yesterday. does this mean, you changed the code and update is save?

Downgrading was a pain in the *ss 😉

patience4711 commented 1 year ago

Yes i thought it would discourage others. I was a small bug in the healthcheck, without debug info very hard to find. Talking about pain in the *ss....

swbouman commented 1 year ago

You’re a hero!

patience4711 commented 1 year ago

@swbouman did you install it?

I am currently testing with some other changes but than it will be mature. The gain in free heap from all the recent updates is evident,

heap_chart

swbouman commented 1 year ago

@patience4711 , I installed it but zigbee coördinator failed all the time. I had to revert back. I run 9.10 now with an uptime of 1 day and free heap of 19280. the heap sensor at mqtt topic /inverter/heap stopped working from of ver 10. So no graph for me anymore.

patience4711 commented 1 year ago

I have currently v9_12 running and thorough tested, You can try this. The only drawback is that you have to re-pair your inverters or change the id via console eg: if inverter 0 has the id = 0xA1B2 you can change this with 10;edit=0-B2A1. This is a bit inconvenient but the change in the notation of the inv ID has many advantages as to free heap and program space. At this moment i don't think than i can do anything else to improve the heap so for now this is the last revision.