Troubleshooting

Question. Would using the "ClearEepromConfig" sketch, do anything nasty to the sencebender gateway eeprom?

@Yveaux Yes, that is what the sencebender gateway was for, so I could start with an easily swappable item, and the core of the network, however you might remember that I am having issues with sencebender gateway.. with no solution in sight. link text

@TheoL Thanks for responding and sorry for my late reply. I finally got an Arduino Nano working as a gateway with RFM69. It required new/different logic converters as the ones I had apparently were not working correctly. I can give the RFM69 3.3V power from the Nano, but as the Nano has 5V logic and the RFM69 cannot handle 5V logic as input (NSS, SCK, MOSI) , the logic converters are needed to protect the RFM69 module as also stated in the MySensors radio guide. I must say that using NRF24 was much easier than using RFM69, but I will stick with RFM69 (433 MHz) for range reasons.

This solved my issue!! Thank you!!

@pw44 downgraded ESP from 3.0.1 to 2.7.4 and issue is gone.

Update: The issue seems to be with the Mega Mini board. I managed to remove the Adafruit RFM69HW daughter board from the verroboard, and wired this to a Nano, and a Teensy 3.2. Both worked with the same PSU. The USB converter however is still giving garbage , no matter which of the three sources above. So I am in the belated process of porting code to the teensy as the target. Many thanks for the help to you all. Now, if I can only sort out my sensebender gateway problem....

@skywatch Just to add to your points on 254 max children, definitions, presentation, etc., which may help @mrmuszynski at some stage. I've an array in a sketch with 14 DS18B20 addresses, all paged in turn using the one wire protocol on a single pin, so it is entirely possible to hit the 254 children limit before looking at I2C devices. The beauty of the DS18B20 array is individual chips are "defined" sequentially, hence making presentation and fetching values available to a FOR loop, which makes for a highly compact sketch.

@djdehaan as soon as somebody spends enough time to figure out how to do it (if it can be done) and submits a working solution.

@skywatch that helped! resolved, thank you!

Maybe diggin a topic a bit, but as for June 2021 : In library file MyHwSTM32.h one line seems to be lost : #ifndef MyHwSTM32_h #define MyHwSTM32_h #include <IWatchdog.h> #include <itoa.h> #include <SPI.h> #include <EEPROM.h> <<--- this is necessary to compile agains BluePill and something like this in platformio.ini [env:bluepill_f103c8] platform = ststm32 board = bluepill_f103c8 framework = arduino upload_protocol = stlink debug_port = stlink debug_tool = stlink monitor_speed = 115200 monitor_filters = time, default Just to keep you entertained. Cheerz.

I want to share an interesting case about updating the firmware over FOTA.. I have several nodes on a RS485 bus with memory chips. Recently I decided to update the firmware on several at once and ran into an unexpected problem - repeated attempts to update constantly ended up with a checksum error !OTA:FWP:CRC FAIL. At the same time, I usually test all new nodes for FOTA firmware updates before installing. I tried to understand what the problem might be and came to an unexpected result - in my case, disabling the directive OTA_EXTRA_FLASH_DEBUG, which I had been using for a long time, when I first tested updates, helped. After disabling this directive, all firmwares were updated the first time. Very strange, but nevertheless ...

@bonamin thanks for reporting back!

@lood29 When I use TTGO LORA as a dummy sensor (Node 10 in the above log) it always works without any nacks. The NACK only appears when I connect my own sensor (Node 140 in the log above). So Scenario 1 Dummy sensor (TTGO LORA) <-> MQTT gateway (TTGO LORA) -> Works Scenario 2 My sensor <-> MQTT gateway (TTGO LORA) -> NACK in the Gateway.

@BearWithBeard Making the change that you suggested returns the expected results! Thanks for suggestion.

I suppose you are using a arduino pro mini when you speak of a newbie board. So effectively it is not easy to connect a laptop to the serial output. I don't think the arduino will reset when connecting, but it's not convenient. So to detect if it is the relayboard, can you deconnect it from the newbie board and let run the node like this. If it works now for some time, we are sure it is the relayboard somehow influencing the arduino. If it still freeze, it is not the relayboard and we must continue to debug...

I found the proximate cause for this problem and posted it in an already opened issue. https://github.com/mysensors/MySensors/issues/1077#issuecomment-832228721

@maddhin FWIW I always use the adafruit library for htu21D and it has a similar test in setup that does not give me any errors - might be worth a try?

@smilvert said in GWT:TPC:CONNECTING: A ticket is raised quite long time ago Thanks a lot... I put my case there also, maybe can help. That gui use same ESP32 DevKit V1 like me. Strange that I didn't fount that page in this 2 days of research. Thanks a lot Denis