ingoogni

Yes. The only way to know a state is to measure/determine it and not depend on data from the past, regardless where they come from DB, Broker, EEPROM...

[testrecord.zip](https://github.com/johnnovak/easywave/files/8663138/testrecord.zip) wav, scripts to generate and read wav & .exe's

I'll add it here as it it also about the documentation. `https://watchdog.readthedocs.io/en/latest/` leads to the 0.9.0 documentation, not to 0.10.3 `https://python-watchdog.readthedocs.io/en/v0.10.3/api.html` has no doc on several parts of the api...

In an attempt to isolate the problem I set up a separate system for one device measuring, a broker and a client only listening. After some time I intentionally reboot...

Thanks for looking in to it. When I simulate it like you do, I get the same results as you do. The problem that occurs with the rebooting of the...

``` rx> PingResp(00): Closing: remote closed connection tx> Disconnect(00): Connecting to 192.168.1.11:1884 Error connecting to 192.168.1.11 The remote computer refused the network connection. ``` That is the nmqtt subscriber client....

Pulling the whole device from the power socket so it stops sending data has the same result. After some time the broker quits. Another situation works fine. I start the...

Without going through the whole process and would probably understand half of it I noticed: In `keepAliveMonitor` state is set to `error`. Then `close()` is called. `close()` does not check...

Tested it today with Mosquitto, nmqtt_sub and the Shelly. No problem. I can reset the device, it goes off-line, comes back on-line and everything continues as it should. Same when...

When I stop (ctrl-C or taskmanager) a nmqtt client, the broker prints ``` Client >> nmqtt_client_name [...] s: ..disconnected.. ``` The after ~60 seconds the broker prints: `Connections >> nmqtt_client_name...