Timm Bogner

> Periodically generate a FDRS message indicating a time issue so it can be sent to the front end. Like an alarm condition. Excellent idea! We can use `INTERNAL_ACT` to...

Ayyo, now it's working! Had to switch to using `radio.transmit()` instead of `radio.startTransmit()`. My setup is 00_MQTT->01_Serial/ESP-NOW->02_ESP-NOW/LoRa->03_LoRa I'll be playing with it alot more in the next few days, plus...

>My code is working with: That's interesting, does it still work for you with my change? >Wonder what's going on. It must be a timing thing. This low-level LoRa is...

I added some debug messages and the transmissions began working. I believe I found the problem. In `sendTimeLoRa()` you run `transmitLoRa()` twice in a row with no delay. If you...

I assembled some console recordings to demonstrate. `*INT*` is printed when the interrupt itself is called. The rest of the new debug messages are either commented out in the existing...

This is all fantastic! Sorry I've been a little unresponsive. I haven't been able to test the newest commit because of some issues with my WiFi. I think the router...

Ethernet seems to work out-of-the-box! I haven't fully digested all of the code and the various rules and expected behaviors yet. As such, I'm still not sure what the special...

I love that you did it all without the time.h library. That definitely is better than I could have made it. My (literally) only concern presently is the DNS config....

Great question. It's actually the **_big_** question for me in terms of timekeeping. First, you're right. The convention I've been using is for LORA1 to be towards the front-end and...

I think it should send to all neighbors, just in case. A fringe configuration that is currently possible is that the gateway connected to the internet has two different neighbors,...