Closed manon24 closed 6 years ago
stefanbode
commented
6 years ago Yes this is because arendst does not complain about a wrong fingerprint, which is wrong in my mind. Please obtain the right fingerprint from your Mqtt broker and the error should be away. If you allow a connect with a wrong fingerprint you share your password with a potential attacker
manon24
commented
6 years ago Just to clarify. Does the 'arendst' code still connect with MQTT broker with an invalid fingerprint?
manon24
commented
6 years ago I changed the fingerprint in 'arendst' code and still obtained connection !! I am running a local Mosquitto broker. I will use your code fork and try to figure out what is wrong as I want to use your 'deepsleep' implementation.
stefanbode
commented
6 years ago Yes the original code connect anyway. I use TLS for all my devices therefore I can confirm that this part is for sure running and has no bugs.
stefanbode
commented
6 years ago There should be a description how to get the fingerprint in the wiki of arendt. But I do not know right now where.
manon24
commented
6 years ago This is the command for obtaining fingerprint from MQTT broker.
openssl s_client -connect localhost:8883 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
manon24
commented
6 years ago I now have your fork working. After almost giving up, as I couldn't find anything wrong with the fingerprint etc. from my MQTT broker, I noticed the '#define CFG_HOLDER xxxxx". Changed this to a different value and now working. Thanks.
stefanbode
commented
6 years ago Yes, both forks are not 100% compatible with the config holder. You have to do a "reset 2" or change the config holder to ensure the holder match to the program code. I'm not able to avoid all side effects because I had to add additional variables.
manon24
commented
6 years ago Can I just confirm with you my 'deepsleep' observations. Sending a MQTT topic with 'DEEPSLEEP 900' ie. 15 minutes I observe a 'LWT=offline' and the device goes into deepsleep. After 15 minutes or so the device is reset and the device is back on line for a few minutes and then goes into 'deepsleep' mode again. It repeats this process. Is this correct?
From your code it would appear the device should only go into 'deepsleep' mode once unless the 'deepsleep' value is greater than 3600 ( 1 hour). For example setting 'deepsleep' to 4500 the device wakes up after one hour and then sleeps for the remaining 15 minutes at which time it resets again, restarts and that is the end of the 'deepsleep'.
stefanbode
commented
6 years ago Mostly correct. In the second case, there is a small wakeup 0.3s after 1h to go to deepsleep again for the remaining 15min. Then there is a wakeup and full start and measurement. You also should see some messages in your MQTT broker now. After successful measurement, the deepsleep cycle with 4500 starts again. The intermediate wakeup is only visible in the console log file (RX,TX), because no other system is up and running.
manon24
commented
6 years ago One possible issue I have come across. If you choose a 'deepsleep' value of greater than 3600 (1 hour) ultradeepsleep is stored in RtcSettings and RTCmemory. If you change your 'deepsleep' value to less that 3600 expecting a sleep period of less than 1 hour, RTCSettings.ultrasleep and RTCmemory, do not get updated to reflect this new condition ie. set to zero. At least that is what I seem to observe.
stefanbode
commented
6 years ago Yes agree. This is a bug. Will fix it later on with new commit.
Cannot obtain MQTT TLS connection. Always receiving 'insecure connection due to invalid fingerprint'. The same user_config .h settings are used in 'arendst' version with no problem.