Data upload stopped

My sensor has stopped uploading data to, but it is still uploading ok to other services like

  • This is a sensor I’ve had since 2019.
  • I recently moved house, so updated the address in the settings page, and also renewed the SDS011 sensor and upgraded the temperature sensor to a BME280.
  • It was uploading fine yesterday evening when I first set it up at the new address, but today the problem started happening.
  • The WiFi quality was around 50% so I thought that was the problem, but placing the WiFi access point out near the sensor to increase the quality to 100% still doesn’t solve the problem.

Chip ID: esp8266-14063112
Debug log:

airRohr: NRZ-2020-133/DE
mounting FS...
opened config file...
parsed json...
output debug text to displays...
Connecting to Bonny Doon
....SNTP synced: Wed Mar 13 18:37:32 2024

WiFi connected, IP is:
Starting Webserver...

ChipId: 14063112

MAC Id: 68c63ad69608
Read SDS...: 23-06-26(ca5e)
Stopping SDS011...
Read BMxE280...
Trying BMx280 sensor on 76 ... found
Send to :
Auto-Update active..PM10:  19.35
PM2.5: 10.43
## Sending to - SDS011
Temperature (°C): 10.75
Pressure (hPa): 101059.34
Humidity (%): 57.90
## Sending to - BME280
## Sending to 
Succeeded -
## Sending to opensensemap: 
Succeeded -
## Sending to Server FS App: 
Succeeded -
Time for Sending (ms): 751

Device status:

Parameter	Wert
Firmware	NRZ-2020-133
Free Memory	30576 
Heap Fragmentation	11 %
Last OTA	2 min, 56s 
NTP Sync	1 
NTP Info (?) reachable: Yes 
Zeit (UTC)	Wed Mar 13 18:40:31 2024  
Uptime	2 min, 56s 
Reset Reason	External System 
SDS011	23-06-26(ca5e) 
WiFi	0/-46/0 
OTA Return	connection failed 
Sensor.Community	2 
Data Send Return	connection failed 
SDS011	0 
Anzahl Messungen	1 
Dauer Messübertragung	751 ms

Same here. Three of my sensors stopped uploading data to at 03:21 UTC+1 last night (all are from nettigo with firmware NAMF-2020-46rc1 or NAMF-2020-45).
Disabling HTTPS for fixes it. But this should be no permanent solution.

There must have been some changes to the SSL config or the certificate.

No problems with, and OpenSenseMap.

Switching off HTTPS also works for me. Thanks for the hint!
Agreed this should not be a long term solution.

You’re welcome.

It seems the culprit is the new RSA certificate issued for yesterday, Tue, 12 Mar 2024 22:40:14 UTC.

I just compiled the nettigo firmware with this little change and HTTPS is working again:

diff --git a/platformio.ini b/platformio.ini
index fceb2c6..b4cb4a4 100644
--- a/platformio.ini
+++ b/platformio.ini
@@ -17,7 +17,6 @@ extra_configs =
 build_flags =

Removing the BEARSSL_SSL_BASIC definition makes the firmware aware of all available ciphers and the sensor now uses the EC certificate from Sun, 28 Jan 2024 22:40:10 UTC.

Some more background on this issue (and why it popped up now):

On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.

The Firmware (airrohr and nettigo) uses this old X3 certificate, so the certificate chain is broken with all certificates from Let’s Encrypt issued after Feb 8th, 2024 resulting in broken HTTPS connects:

See: ca-root.h

This means the API from madavi and other sites using certificates from LE (mostly all of them do that) will be unreachable via HTTPS after their next certificate renewal in the next days or weeks.

O.M.G it means https is broken everywhere on the SC Network ?

At this moment it looks like, and still/again use a cross-signed certificate chain. So until the next renewals all should be fine.

@DaleBCooper could you try the patch at Replace DST Root CA X3 with ISRG Root X1 · Phaze-III/sensors-software@80cc87f · GitHub to see if that helps? The patch should cleanly apply to both the beta and master branches of the SC firmware, not sure about Nettigo.

I’ve been running the SC firmware with that patch for almost a year now and HTTPS uploads and downloads to/from the various servers work and should also work when the cross-signed intermediates expire or are removed.

1 Like

Nettigo fixed it today and released a new version an hour ago:

Will test it later, but I think this should fix the issue.


is there any update on this issue? Esp. for airrohr-users? I disabled SSL as a workaround, which sends data, but - obviously - OTA is broken (https), so I think a manual update will be necessary, but the latest airrohr firmware I find is the 2020-133 which I have installed already…


1 Like

There is already a pull request from @Phaze-III at github including an instruction how to temporarily fix the OTA update:

Somebody at opendata-stuttgart needs to merge it and fix the certificate. This is no big deal.

1 Like

This PR will fix the firmware but for OTA upgrades and uploads to actually work with the installed base the certificates on the various SC-servers most likely will need to be ‘downgraded’ to RSA keys. Currently the server certificates are using “Public key type EC/secp384r1” . The deployed firmware can’t cope with that as you already noticed. Changing (server side) to RSA should make it work again.

I don’t know what mechanism is used on the SC-servers to renew certificates but when using certbot that would be something like:

certbot --force-renewal --preferred-chain 'DST Root CA X3' --key-type rsa

This also will keep the ‘old’ chain active to keep serving the installed base.

As a first step it would be even sufficient to go back to the previous certificate, which should be still valid for more than 20 days.
But only if a project member would merge your PR and build the firmware asap.

At this moment all SC-servers do have a certificate with the old chain which should work for the next few weeks so I can only assume that they are running the previous certificates.

There are however still connection failures for OTA upgrade checks and possibly also uploads which might be related to other recent changes in the server-side SSL-config. key-type is my first guess but without actually knowing what changed that’s just a guess.

Good news. They renewed the certificate:

   Issuer                       R3 (Let's Encrypt from US)
   Certificate Validity (UTC)   89 >= 30 days (2024-03-16 17:21 --> 2024-06-14 17:21)

Most sensors seem to be back at since the early evening.
About 11.400 right now vs. about 9.200 sensors before the certificate change.
At the end of February I saw about 11.900.

1 Like

Good news indeed. And with a forced renewal a few days before Thursday, June 6th, 2024 will extend the time left before the definite expiration of the cross-signed root with another 90 days.

OTA checks still give a connection failure. It looks like and the other SC-servers serve certificates based on used protocol/capabilities and uses a non-cross-signed certificate when connecting with an ‘old client’ similar to the sensor firmware:

Certificate chain
   i:C=US, O=Let's Encrypt, CN=R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar  5 22:36:29 2024 GMT; NotAfter: Jun  3 22:36:28 2024 GMT
 1 s:C=US, O=Let's Encrypt, CN=R3
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT

Replacing that one should fix the OTA part.

@ricki-z Much better now, thanks :wink:

Certificate chain
   i:C=US, O=Let's Encrypt, CN=R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Mar 17 09:19:11 2024 GMT; NotAfter: Jun 15 09:19:10 2024 GMT
 1 s:C=US, O=Let's Encrypt, CN=R3
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   i:O=Digital Signature Trust Co., CN=DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT

OTA is working again.

Seems like a network problem. I had the same with two of my sensors but they started showing up on the map again since yesterday evening.

This is still an issue for any devices sending data to services using newer SSL certs.

I’m using opensensemap, which is hardcoded to HTTPS in the firmware (I’m unsure is opensensemap support unencrypted connections). OpenSensemap curerrently have a message up about the issue on their site.

@Phaze-III ’s PR updates the root cert on the device firmware to allow it to resolve/validate newer certs successfully.

Any chances of getting it merged/built/deployed OTA?

Otherwise I’m going to have to try to build locally (haven’t had an environment set up for a few years) go retrieving devices and re-flashing them manually, which is going to take a while (I was supposed to be using some for a baseline for a project involving closing streets near schools to measure the impact).


all uploaders to SenseMap are waiting for an update too, because this is also failing and SSL could not be deactivated in config for SenseMapApi.

New firmware with the fix is very appreciated.

What’s missing? Can I help out?

We are working on this. As a reminder we are a volunteered project, doing all this in our spare time (while OpenSenseMap got millions of EU fundings …)
The problem is that we need to support 2 root certificates for some time until all devices are updated. And that the OTA update needs some more testing as we will lose even more devices (possibly all) when they can’t start anymore after the update.