T41 - Homekit mplementation stops after several hours

[kranfahrer]

Hi all,

I have a problem with my program and I don’t know how to find the error. I have spend days/weeks finding the error but I have no idea what else to do…

I have ported my Homekit implementation over to the Teensy 4.1 (with heavy modifications) and it works quite well. Except after a few hours it stops/hangs.

The code consists of several thousand lines of code, so it is difficult to post the code here. It also uses mbedtls v2.18 and vjmuzik’s NativeEthernet Library, ArduinoJson, TeensyID and a few other libs.

Additionally to the „normal“ Apple like Homekit, I also implemented something like fakegato to show a graph of the values measured in the past like in the Elgato EVE app. Therefore I use the CircularBuffer library. To get the correct timestamp of each measurement, I use a NTP client and the Timezone library. (Syncing time is every 10 minutes).

My problem is, if I run the program for several hours, just „measuring“ a dummy BME280 sensor (actually it just generates random numbers) every 5 seconds and stores it as a struct in the CircularBuffer and the buildin LED blinks every second. These values are tied to specific Homekit Accessories, Services and Characteristics which are updated for each measurement.

There isn’t any other hardware involved except the „LAN Socket Shield“ from PJRC.

Additionally I write out the free heap, stack and maxstack every second over the Serial. If there would be a memory leak, the free heap value should decrease over time, but it isn’t… The other values are (more or less) constant as well.

During my tests, there is no connection from clients over network. So all the „heavy“ stuff like SRP and encrypting/decrypting functions aren’t called at all. I do not use the provided Webserver but I have written my own. It will check for new connections each loop.

I have decreased the „waiting“ times between each measurement (to speed up the things). I would expect, that the program would stop a lot earlier, but it also runs for several hours.

I tried to avoid Strings and instead switched over to std::string and/or char arrays. The functions called during this tests, don’t use Strings at all.

I tried several things, like

• NTP doesn’t seem to have impact, because without NTP it will hang as well
• I tried to replace all Strings with std::string or char arrays
• Speed up my program by reducing „waiting“ times (from seconds to 1-2ms)
• Avoid logging or printing out to Serial
• Different versions of Teensyduino (1,53 - 1,54 and the Betas)
• Different compile options like fast, faster and so on
• changed most of the pointers to smart (shared_ptr) pointers

But it will still hang/stop after several hours… i would say without any mayor difference.

I use platformio with the upstream teensy-platform (v1.54) and macOS for compiling. The Teensy 4.1 is connected to a RaspberryPi 4 via USB and I am logging the Serial output via screen and to a file as my test setup.

There is also no Crash Report after I reset the teensy with tycmd after the program stops/hangs. The last lines on my logs from each test vary in timestamps (= running time) and messages.

These are the last lines of my latest test using smart ptrs.

[D]  16978136 | 2021-07-17 04:00:25 | HAPFakegato.cpp      [  145] addDataToBuffer | Adding entry for 0CD851-BME280-DUMMY [size=100 bitmask=7] - data length: 6
[W]  16978136 | 2021-07-17 04:00:25 | HAPFakegato.cpp      [  157] addDataToBuffer | WARNING: Fakegato entry will be overwritten!
[V]  16978137 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  130] handleImpl | [BME280] - Handle plugin [1]
[I]  16978137 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  118] changedTemperature | [BME280] Changed temperature: 27.50 >>> 36.30
[I]  16978137 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  122] changedHumidity | [BME280] Changed humidity: 29.00 >>> 22.00
[I]  16978137 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  126] changedPressure | [BME280] Changed air pressure: 430 >>> 1060
[V]  16978138 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  130] handleImpl | [BME280] - Handle plugin [1]
[I]  16978138 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  118] changedTemperature | [BME280] Changed temperature: 36.30 >>> 28.20
[I]  16978138 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  122] changedHumidity | [BME280] Changed humidity: 22.00 >>> 35.00
[I]  16978138 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  126] changedPressure | [BME280] Changed air pressure: 1060 >>> 890
[D]  16978138 | 2021-07-17 04:00:25 | HAPFakegato.cpp      [  145] addDataToBuffer | Adding entry for 0CD851-BME280-DUMMY [size=100 bitmask=7] - data length: 6
[W]  16978138 | 2021-07-17 04:00:25 | HAPFakegato.cpp      [  157] addDataToBuffer | WARNING: Fakegato entry will be overwritten!
[H]  16978139 | 2021-07-17 04:00:25 | HAPServer.cpp        [  926] handle | heap:382544 | mem:113676 | stack:113696 | clients: 0 | queue: 0 
[V]  16978139 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  130] handleImpl | [BME280] - Handle plugin [1]
[I]  16978139 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  118] changedTemperature | [BME280] Changed temperature: 28.20 >>> 34.10
[I]  16978139 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  122] changedHumidity | [BME280] Changed humidity: 35.00 >>> 30.00
[I]  16978139 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  126] changedPressure | [BME280] Changed air pressure: 890 >>> 600
[V]  16978140 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  130] handleImpl | [BME280] - Handle plugin [1]
[I]  16978140 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  118] changedTemperature | [BME280] Changed temperature: 34.10 >>> 35.60
[I]  16978140 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  122] changedHumidity | [BME280] Changed humidity: 30.00 >>> 25.00
[I]  16978140 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  126] changedPressure | [BME280] Changed air pressure: 600 >>> 840
[D]  16978140 | 2021-07-17 04:00:25 | HAPFakegato.cpp      [  145] addDataToBuffer | Adding entry for 0CD851-BME280-DUMMY [size=100 bitmask=7] - data length: 6
[W]  16978140 | 2021-07-17 04:00:25 | HAPFakegato.cpp      [  157] addDataToBuffer | WARNING: Fakegato entry will be overwritten!
[V]  16978141 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  130] handleImpl | [BME280] - Handle plugin [1]
[I]  16978141 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  118] changedTemperature | [BME280] Changed temperature: 35.60 >>> 30.60
[I]  16978141 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  122] changedHumidity | [BME280] Changed humidity: 25.00 >>> 28.00
[I]  16978141 | 2021-07-17 04:00:25 | HAPPluginBME280.cpp  [  126] changedPressure | [BME280] Changed air pressure: 840 >>> 310

Any idea how to find and fix this error would be highly appreciated.

Link to repository: https://github.com/An00bIS47/Teensy_Homekit


Thank you very much!

[bicycleguy]

I hate it when that happens

Especially when I have custom hardware and programs so convoluted nobody wants to look at it.
A few thoughts:
1. The new 1.54 Teensduino with the CrashReport turned on is really useful. You mentioned it but didn't mention how it automatically reboots after 8 secs. Does it? If it doesn't then your likely stuck in a self induced loop somewhere. Put print statements in rarely used or unexpected loops.
2. TeensyID will cause crashes or failures to restart if used outside of setup, in seemingly random ways. Not sure why, but GitHub author confirmed. So write to a global in setup once.
3. Lots of Teensy libraries are incompatible with each other in yet to be figured out ways. I'd try to remove them one by one starting with the NativeEthernet library. There's a reason the ethernet functionality is usually relegated to a separate chip. Eventually it will get ironed out but its new here. Type 'site: forum.pjrc.com NativeEthernet' into your browser and see what I mean. I'd try someones 'shield' in the mean time.

[defragster]

As noted TD 1.54 CrashReport can be handy if the code faults, and on ones it can handle it will pause 8 secs. Some can InstaReboot around it - but that doesn't seem the case here.

Have seen loop() calls get stalled but isr()'s still running.

If an LED can be put on a spare pin set up an intervalTimer to Toggle it.

If that LED blink keeps running then there is life ... it just may be stuck. It won't say 'where or why' - but may give ideas for resolution.

CrashReport works by counting on the static nature of DMAMEM/RAM2. If there are things showing status or debug a private version could put a struct or other for info into DMAMEM and print that in setup(). That only works when the cache is flushed out to RAM2 before restarting.

This shows that to some degree. Playing with Watchdog code example all is well until the user sends Serial input that purposefully halts the feeding of the watchdog leading to a reset. You can see in the myCallBack some DMAMEM vars are _flush()'d and then the Serial bytes are read and saved to a sz char array before the reset can trigger - then that is printed in setup()

It may have some utility? And the dcache_flush could be done in the intervalTimer with the blink to assure the cache is pushed to RAM2 as it is lost on restart.

#include "Watchdog_t4.h"
WDT_T4<WDT3> wdt;

// https://forum.pjrc.com/threads/67649-Non-volatile-data-for-debugging-RTWDOG-reset?p=283532&viewfull=1#post283532
// https://github.com/TeensyUser/doc/wiki/The-Watchdog-timer

// DMAMEM causes allocation in 'static' RAM2 on Teensy using 1062 processor
// It is not initialized and will retain value while powered
// BUT - it writes through a cache that must be flushed to assure it is current
// This works for any DMAMEM allocation of any variable type or structure
DMAMEM uint32_t loopCnt;
DMAMEM uint32_t feedCnt;
DMAMEM char szLast[32];

void myCallback() {
  arm_dcache_flush(&loopCnt, sizeof(loopCnt));
  arm_dcache_flush(&feedCnt, sizeof(feedCnt));
  uint ii = 1;
  while ( ii < (sizeof(szLast) - 1) && Serial.available() ) {
    szLast[ii++] = Serial.read();
  }
  szLast[ii] = 0;
  szLast[0] = 42;
  arm_dcache_flush(szLast, sizeof(szLast));
  Serial.println("YOU DIDNT FEED THE DOG, 255 CYCLES TILL RESET...");
}

void setup() {
  Serial.begin(1);
  delay(600);
  Serial.println("Begin......");
  Serial.print("\tPRIOR Loop Count = ");
  Serial.println(loopCnt);
  loopCnt = 0;
  arm_dcache_flush(&loopCnt, sizeof(loopCnt));
  Serial.print("\tPRIOR Feed Count = ");
  Serial.println(feedCnt);
  feedCnt = 0;
  arm_dcache_flush(&feedCnt, sizeof(feedCnt));
  if ( szLast[0] == 42 && szLast[1] != 0 ) {
    Serial.print("\tLast User input text : ");
    Serial.println(&szLast[1]);
  }
  szLast[0] = 0;
  arm_dcache_flush(szLast, sizeof(szLast));
  if ( Serial && CrashReport )
  { // Make sure Serial is alive and there is a CrashReport stored.
    Serial.print(CrashReport); // Once called any crash data is cleared
    // In this case USB Serial is used - but any Stream capable output will work : SD Card or other UART Serial
  }

  WDT_timings_t config;
  config.window = 3000; /* in seconds, 32ms to 522.232s, must be smaller than timeout */
  config.timeout = 10000; /* in seconds, 32ms to 522.232s */
  config.callback = myCallback;
  wdt.begin(config);
}

void loop() {
  static uint32_t feed = millis();
  loopCnt++;

  /* set to below 3000 to demonstrate windowMode effect for feeding the dog too fast */
  /* set to 3100 to demonstrate proper processing */
  /* set to 12000 to demonstrate an actual non-feeding reset */

  if ( millis() - feed > 3100 ) {
    feed = millis();
    wdt.feed();
    feedCnt++;
  }
  if ( Serial.available() ) { // Any Serial input will HALT the loop() here causing WD Timeout
    Serial.println("Hungry Dog ahead ...... code stopped here restart pending ...");
    while ( Serial.available() );
    Serial.println("Too late - but callback emptied the queued data!"); // this prints if the timing is right - then restart
  }
}

[kranfahrer]

Hi bicylceguy,

thanks for your response

I will try to answer your questions:

1. The CrashReport doesn't reboot automatically, the program just hangs/stops. I will try to add more print statements in functions. There are some functions which rely on a timeout, maybe it gets stuck somewhere there
2. Thanks for mentioning the problem with TeensyID. I will try to avoid the TeensyID at all
3. I tried to remove or at least not use functions regarding some of the additional libraries I am using, but leaving out the NativeEthernet is a task for itself I will have a look how I can do this

Currently the program is running for 13 hours+ and I had to delete my logs because the SDcard on the raspberry pi was full

[kranfahrer]

Hi defragster,

thank you for your response!

I will try to add a watchdog timer for a blinking LED as well. I haven't worked with watchdog timers yet but the code you posted is definitely helpful. I will report back when I have implemented it and tested it, but this will take some time.

As I already have written, the program is currently running. Although it is running a lot longer than in the excerpt from the log, I am just waiting for it to stop since there haven't been any significant change in the code.

[vjmuzik]

This is related to a known bug with anything using NativeEthernet’s Server code, specifically with this line here: EthernetClient client = _server.available();. The short end of the story is that eventually you run out of sockets so ethernet stops working when that happens. We have a general idea that the error is happening in FNET’s TCP code, but I’m not sure if Paul has had a chance to look yet.

[defragster]

Hi defragster,

thank you for your response!

I will try to add a watchdog timer for a blinking LED as well. I haven't worked with watchdog timers yet but the code you posted is definitely helpful. I will report back when I have implemented it and tested it, but this will take some time.

As I already have written, the program is currently running. Although it is running a lot longer than in the excerpt from the log, I am just waiting for it to stop since there haven't been any significant change in the code.

The watchdog was just incidental to that example showing after restart DMAMEM can hold usable information if there is something that can be pulled from memory if saved.

It was the intervalTimer - not shown - that would trigger the Blink toggle at some rate and perhaps update and dcache_flush useful info to the DMAMEM if applicable as a monitor tool.

The post by vjmuzik about ethernet points to a possibly known issue causing trouble.

The watchdog restart may allow recovery if that would help.

[kranfahrer]

Hi vjmuzik

thanks for you response!

This is related to a known bug with anything using NativeEthernet’s Server code, specifically with this line here: EthernetClient client = _server.available();. The short end of the story is that eventually you run out of sockets so ethernet stops working when that happens. We have a general idea that the error is happening in FNET’s TCP code, but I’m not sure if Paul has had a chance to look yet.

If I understand this correct, this would only cause trouble, if there is a connection from one or multiple clients, correct? During my tests I have no connection from any client to my Teensy... but I will keep this in mind!


Thank you for looking into this and for your help

[vjmuzik]

I missed the part where you said no clients were connected, but yes this specific problem should only occur when clients connect, doesn't matter if one or multiple, eventually it happens.

[kranfahrer]

Hi all,

I just wanted to report back some updates.

After my latest test, it looks a bit different. Currently it is running since 2021-07-20 with a „waiting“ time of 1 ms and the LED is still blinking (without implementing watchdog). But I have no output from the Serial any longer.

The output stopped at 2021-07-23-00:12:39 but as I said, the LED is still blinking so the program itself must be still „alive“. If there would have been a reset/restart, the main loop (and the blinking) would not even start since it waits for a Serial connection at the start of the setup.

For keeping track of the Serial output I have written a small script which only keeps the latest 500 lines in memory.

This is the summary of the script:

Summary:
Runtime from 2021-07-20-23:52:02 to 2021-07-23-00:12:39
Duration: 2 days, 0:20:36.867410
Last Line: 
[V]  178465933 | 2021-07-23 00:12:37 | HAPServer.cpp        [ 1041] handle | Handling Events ...>> 35.80

I can connect with „tycmd monitor“ but there is no output whatsoever:

tycmd monitor -r
Monitoring ‚8418090-Teensy'

All my logging macros use "printf"

BTW: For my tests I use the „dev“ branch and the „teensy_41_debug“ environment from the platformio.ini

[defragster]

Comforting ... but disturbing to have the blink ...

Not sure what _isr() looks like for the blink. Sounds like it is working as intended.

Again, the watchdog code was not suggesting you needed that - though it would restart if loop() code stalls and it is feeding the dog.

The watchdog code was to show using DMAMEM static storage so on restart any useful info and status of the program could be stored and recalled after Serial.printf() stopped working to debug that might help uncover where it is stalled or why it stalled.

[kranfahrer]

defragster, the blinking is done within a loop and delay. No _isr or interrupts are used for the blinking.

In the meanwhile the LED also stopped blinking

I have restarted the Teensy manually and want to try another test. There were no changes to the code yet.

Thanks again for pointing out your example with the watchdog. I have read the code carefully and now I understand what you wanted to tell me with that. I will implement it in the next days and report back once I have tested it. Unfortunately those tests are very time consuming

[defragster]

Okay, good luck.

p#3 suggested " intervalTimer to Toggle " LED = if it was in loop() then that was still running - suggest something is trashing USB Stack if that stops.

Using the intervaltimer _isr() for the LED toggle would have indicated something else or additional if it kept running when loop stopped.

And something will need to do the dcache_flush to have that data mean anything as the example shows.

[kranfahrer]

Hi defragster,

First of all I really appreciate your help and thank you for this! And sorry for being a bit slow with understanding what you suggested with your previous posts!

The last test failed after only a few hours, so my previous changes hadn’t any impact regarding this.

I have now implemented the intervalTimer as you suggested and as explained here https://www.pjrc.com/teensy/td_timin...rvalTimer.html. Therefore I added another LED on PIN 41 and it is blinking now.

For the other example I am currently thinking about what information would be helpful to have saved in DMAMEM.

I will also search for a power adapter and have another test without any USB Serial connection (only for powering the Teensy over USB)

I will report back once I have some updates.

Thanks again!

[kranfahrer]

Hi all,

I just wanted to report back some updates.

As written in my post yesterday I have implemented the intervalTimer with a LED which is still blinking. There is no Serial output any longer and the other LED also stopped blinking. So right now only the intervalTimer LED is blinking.

Summary:
Runtime from 2021-07-24-22:58:59 to 2021-07-25-07:42:32
Duration: 8:43:32.960555
Last Line: 
[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [  951] handle | Handle existing clients ...OK

[defragster]

Interesting - some bad stuff happened to stop USB and loop() it seems - seeing the interval timer _isr() LED explains it not faulting.
> most common cause of USB stoppage is writing beyond end of an array, or similar use of a bad pointer?

With access to a set of Serial# UART pins (and GND) and a second Teensy running the USB ECHO - or an FTDI to USB - the _isr() could:
> watch a count incremented on each loop - when that stops changing it could send 'useful' debug info out the Serial# port.
-- > Assuming that loop() cnt stops when the LED toggle stops?
> The same data perhaps saved in DMAMEM - where the _isr() could update that info and flush the cache.
-- > Normally best to avoid such printing from an _isr() - but at this point there is a problem - though it should still be minimal and rare.

If the Serial# output comes through the info would be available sooner, before restarting the Teensy

It seems the USB output stops before the loop() code halts - based on prior notes about LED toggle in the loop()

Perhaps at key points in loop starting a variable uint32_t runLine = __LINE__;
> that runLine might indicate where it is stopping if saved/printed.

Not sure how large the project is #files, functions - but similar tracking of __LINE__ and location info might help point to the problem.

[kranfahrer]

hi defragster,

Thanks for your response and your suggestions!

Perhaps at key points in loop starting a variable uint32_t runLine = __LINE__;
> that runLine might indicate where it is stopping if saved/printed.

i have done something similar with my logging macros. Let me explain the log lines a bit more in detail. I should have done that way earlier...

A log line usually looks like this:

[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [  951] handle | Handle existing clients ...OK
 |     |                |                     |               |      |         +-> User defined message
 |     |                |                     |               |      +-> Function name
 |     |                |                     |               +-> Line #
 |     |                |                     +-> Filename 
 |     |                +-> Date/Time
 |     +-> elapsed Millis
 +-> Log Level

The "loop" function looks like this: (i have left out irrelevant functions behind commented out defines)

HAP_DEBUG is set to 1
HAP_HEAP_LOG_INTERVAL is set to 5

The LOGRAW_V("OK\n"); in the code below printfs just the user defined message.
LOG_HEAP() printfs out the current heap, freemen and maxstack value like this

[H]  31416812 | 2021-07-25 07:42:28 | HAPServer.cpp        [  929] handle | heap:383960 | mem:113668 | stack:113696 | clients: 0 | queue: 0

The heap, mem and stack values are constant throught the last 500 lines of the log. There aren't so many statements

void HAPServer::handle() {


#if HAP_DEBUG
    // Free Heap every interval ms
    if ( millis() - _previousMillisHeap >= HAP_HEAP_LOG_INTERVAL) {
        _previousMillisHeap = millis();
        LOG_HEAP(_clients.size(), _eventManager.getNumEventsInQueue());
    }
#endif


    //
    // Handle existing clients
    //
    LOG_V("Handle existing clients ...");
    for (auto& hapClient : _clients) {

        // Connected
        if (hapClient->client.connected()) {

            // Available
            unsigned long timeout = 15;
            unsigned long previousMillis = millis();
            while ( millis() - previousMillis < timeout) {

                if (hapClient->client.available()) {
                    hapClient->state = HAPClientState::Available;
                    handleClientState(hapClient);
                    break;
                }

                // Idle
                hapClient->state = HAPClientState::Idle;
            }


        } else {
            // Disconnected
            hapClient->state = HAPClientState::Disconnected;
            handleClientState(hapClient);
        }
    }
    LOGRAW_V("OK\n");

    //
    // Handle new clients
    //
    LOG_V("Checking for new clients ...");
    EthernetClient client = _server.available();

    if (client) {
        LOGRAW_V("OK\n");
        LOG_V("Handle new client ...");

        HAPClient* hapClient = new HAPClient();

        // New client connected
        hapClient->client = client;
        hapClient->state = HAPClientState::Connected;

        handleClientState(hapClient);
    }
    LOGRAW_V("OK\n");



    //
    // Handle plugins
    //
    LOG_V("Handling plugins ...");
    for (auto& plugin : _plugins){
        if ( plugin && plugin->isEnabled() ){
            plugin->handle();
        }

    }
    LOGRAW_V("OK\n");

    //
    // Handle fakeGatos
    //
    LOG_V("Handling Fakegato ...");
    _fakeGatoFactory.handle();
    LOGRAW_V("OK\n");

    //
    // Handle any events that are in the queue
    //
    LOG_V("Handling Events ...");
    processEvents();
    LOGRAW_V("OK\n");

}

I have no connection from a client, so blocks using a client or hapclient shouldn't cause any trouble.

Remains the handling of plugins, fakegatos and events. I will have at look at this and check for similar dependencies regarding pointers or the like.

And the heap logging itself... hmm. I will disable this and have another test in the meanwhile.


Additionally here is a summary of the logs of my tests:

Summary:
Runtime from 2021-07-19-23:09:10 to 2021-07-20-11:07:52
Duration: 11:58:41.816272
Last Lines: 
[V]  43388043 | 2021-07-20 11:07:49 | HAPServer.cpp        [  947] handle | Handle existing clients ...OK
[V]  43388043 | 2021-07-20 11:07:49 | HAPServer.cpp        [ 1025] handle | Handling plugins ...OK
[V]  43388043 | 2021-07-20 11:07:49 | HAPServer.cpp        [ 1043] handle | Handling Events ...OK
[V]  43388043 | 2021-07-20 11:07:49 | HAPServer.cpp        [  986] handle | Checking for new clients ...OK
[V]  43388043 | 2021-07-20 11:07:49 | HAPServer.cpp        [ 1036] handle | Handling Fakegato ...OK
[V]  43388043 | 2021-07-20 11:07:49 | HAPServer.cpp        [  947] handle | Handle existing clients ...OK



Summary:
Runtime from 2021-07-20-15:29:56 to 2021-07-20-21:01:02
Duration: 5:31:06.224646
Last Lines: 
[V]  21600375 | 2021-07-20 21:01:01 | HAPServer.cpp        [  947] handle | Handle existing clients ...OK
[V]  21600375 | 2021-07-20 21:01:01 | HAPServer.cpp        [ 1025] handle | Handling plugins ...OK
[V]  21600375 | 2021-07-20 21:01:01 | HAPServer.cpp        [ 1043] handle | Handling Events ...OK
[V]  21600375 | 2021-07-20 21:01:01 | HAPServer.cpp        [  986] handle | Checking for new clients ...OK
[V]  21600375 | 2021-07-20 21:01:01 | HAPServer.cpp        [ 1036] handle | Handling Fakegato ...[D]  21600376 | 2021-07-20 21:01:01 | HAPFakegato.cpp      [  147] addDataToBuffer | Adding entry for 0CD851-BME280-DUMMY [size=100 bitmask=7] - data length: 6
OK
[V]  21600376 | 2021-07-20 21:01:01 | HAPServer.cpp        [  947] handle | Handle existing clients ...OK
[V]  21600376 | 2021-07-20 21:01:01 | HAPServer.cpp        [ 1025] handle | Handling plugins ...[V]  21600376 | 2021-07-20 21:01:01 | HAPPluginBME280.cpp  [  134] handleImpl | [BME280] - Handle plugin [1]
[I]  21600376 | 2021-07-20 21:01:01 | HAPPluginBME280.cpp  [  126] changedHumidity | [BME280] Changed humidity: 23.00 >>> 36.00
OK



Summary:
Runtime from 2021-07-20-22:38:15 to 2021-07-20-22:39:26
Duration: 0:01:10.672179
Last Lines:
[V]     75629 | 2021-07-20 22:39:25 | HAPServer.cpp        [  945] handle | Handle existing clients ...OK
[V]     75629 | 2021-07-20 22:39:25 | HAPServer.cpp        [ 1023] handle | Handling plugins ...OK
[V]     75629 | 2021-07-20 22:39:25 | HAPServer.cpp        [ 1041] handle | Handling Events ...OK
[V]     75629 | 2021-07-20 22:39:25 | HAPServer.cpp        [  984] handle | Checking for new clients ...OK
[V]     75629 | 2021-07-20 22:39:25 | HAPServer.cpp        [ 1034] handle | Handling Fakegato ...OK
[V]     75629 | 2021-07-20 22:39:25 | HAPServer.cpp        [  945] handle | Handle existing clients ...OK



Summary:
Runtime from 2021-07-20-23:52:02 to 2021-07-23-00:12:39
Duration: 2 days, 0:20:36.867410
Last Lines:  
[V]  178465933 | 2021-07-23 00:12:37 | HAPServer.cpp        [  984] handle | Checking for new clients ...OK
[V]  178465933 | 2021-07-23 00:12:37 | HAPServer.cpp        [ 1034] handle | Handling Fakegato ...OK
[V]  178465933 | 2021-07-23 00:12:37 | HAPServer.cpp        [  945] handle | Handle existing clients ...OK
[V]  178465933 | 2021-07-23 00:12:37 | HAPServer.cpp        [ 1023] handle | Handling plugins ...OK
[V]  178465933 | 2021-07-23 00:12:37 | HAPServer.cpp        [ 1041] handle | Handling Events ...[340 >>> 35.80



Summary:
Runtime from 2021-07-24-08:00:50 to 2021-07-24-12:50:10
Duration: 4:49:19.402888
Last Lines:
[V]  17362204 | 2021-07-24 12:50:08 | HAPServer.cpp        [ 1041] handle | Handling Events ...OK
[V]  17362204 | 2021-07-24 12:50:08 | HAPServer.cpp        [  984] handle | Checking for new clients ...OK
[V]  17362206 | 2021-07-24 12:50:08 | HAPServer.cpp        [ 1023] handle | Handling plugins ...OK
[V]  17362206 | 2021-07-24 12:50:08 | HAPServer.cpp        [ 1041] handle | Handling Events ...OK
[V]  17362206 | 2021-07-24 12:50:08 | HAPServer.cpp        [  984] handle | Checking for new clients ...OK
[V]  17362206 | 2021-07-24 12:50:08 | HAPServer.cpp        [ 1034] handle | Handling Fakegato ...OK



Summary:
Runtime from 2021-07-24-22:58:59 to 2021-07-25-07:42:32
Duration: 8:43:32.960555
Last Lines:  
[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [ 1047] handle | Handling Events ...OK
[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [  951] handle | Handle existing clients ...OK
[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [ 1029] handle | Handling plugins ...OK
[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [ 1047] handle | Handling Events ...OK
[V]  31419654 | 2021-07-25 07:42:31 | HAPServer.cpp        [  951] handle | Handle existing clients ...OK

[defragster]

Just pulled a copy of the code - not scanned before - indeed the LOG_... macros look quite extensive in HAPLogging.*! And useful when(while) the requested info actually results in usable DEBUG output.

As always adding debug has the chance to makes things morph or move - either showing the problem sooner or moving the problem. Safe to suppose the behavior is similar when all the logging is made void?

Would be cool if those could do sprintf() to DMAMEM circular buffer - then printf() from there while USB survives - and when USB stops those strings could be dumped on restart if the cached copy was flushed.

[kranfahrer]

hi defragster,

in the repository are a lot of files which aren't used at all for the Teensy or are "old" but not yet deleted or cleaned up.

The relevant files would be the following for the Teensy

	+<HAP/EventManager.cpp>
	+<HAP/HAPAccessory.cpp>
	+<HAP/HAPAccessorySet.cpp>
	+<HAP/HAPClient.cpp>
	+<HAP/HAPConfiguration.cpp>
	+<HAP/HAPDailyTimer.cpp>
	+<HAP/HAPDailyTimerFactory.cpp>
	+<HAP/HAPDeviceID.cpp>
	+<HAP/HAPEncryption.cpp>
	+<HAP/HAPFakegato+Schedule.cpp>
	+<HAP/HAPFakegato+ScheduleEnergy.cpp>
	+<HAP/HAPFakegato.cpp>
	+<HAP/HAPFakegatoFactory.cpp>
	+<HAP/HAPHash.cpp>
	+<HAP/HAPHelper.cpp>
	+<HAP/HAPLogging.cpp>
	+<HAP/HAPPlugins.cpp>
	+<HAP/HAPPrintBuffered.cpp>
	+<HAP/HAPPrintChunked.cpp>
	+<HAP/HAPPrintEncrypted.cpp>
	+<HAP/HAPPrintPlus.cpp>
	+<HAP/HAPRequest.cpp>
	+<HAP/HAPSRP.cpp>
	+<HAP/HAPServer.cpp>
	+<HAP/HAPService.cpp>
	+<HAP/HAPTLV8.cpp>
	+<HAP/HAPTime.cpp>
        +<HAP/HAPConfigurationEEPROM.cpp>
        +<HAP/base36.c>
        +<HAP/concat.c>

and 

	+<Crypto/m_X25519.c>
	+<Crypto/m_chacha20_poly1305.c>
	+<Crypto/m_ed25519.c>
	+<Crypto/m_hkdf.c>

plus the plugins (currently in use is the led and bme280)
       +<HAP/plugins/BME280/HAPPluginBME280.cpp>
       +<HAP/plugins/LED/HAPPluginLED.cpp>

The Webserver, Wifi files etc are or were used for a esp32...

i am not sure if it will compile on your computer, because I have added some extra scripts for adding defines source files and stuff to the build process based on your options set in the platformio.ini. I use macOS as building system

if you have trouble compiling the code, I can make a much simpler platformio.ini for you without any script involved.

[defragster]

Just opened the code to see the macros ...

I build with IDE rules ... usually with command line from Sublimetext ... so not sure I'd try to build ... not sure of the code requirements of purpose ...

Is it a library or is that just the format platform.io uses for storage?

The readme is empty except for a bad link

[kranfahrer]

Safe to suppose the behavior is similar when all the logging is made void?

I messed up the previous test but I have started now another with no logging at all. Let's see what happens

I updated the Readme in the GitHub repo in dev branch with a description how to build/compile with platformio and it also explains a bit more what is additionally done while or before compiling. At least I hope so

Although I do not understand these two "things" but I hope the updated readme will make it a bit more clear.

not sure of the code requirements of purpose ...

Is it a library or is that just the format platform.io uses for storage?