search

opendata-stuttgart / sensors-software

sourcecode for reading sensor data
574 stars 312 forks source link

Replacing a faulty WiFi module #719

Open RikDrabs opened 4 years ago

RikDrabs commented 4 years ago

A faulty WiFi module in a PM sensor needs to be replaced. The owner/user wants to have its "new" PM graphics data in continuation with the "old" PM graphics data. Is it possible to replace a faulty Wifi module with a new one, while retaining the MAC address and Chip-id of the faulty module, and how do I do this? Anyway, the old & faulty module will be scrapped, so no risc for duplicate Chip-id's. Thanks in advance.

RikDrabs commented 4 years ago

The problem doesn't go away. Faulty ESP8266 modules need replacement from time to time, and people keep asking to retain their original chip-ID, to retain continuity in their graphics. A solution please, in one form or the other, since now all old data is lost to the old number, and even the global use of the old and new data is in jeopardy ...

KoffeinKaio commented 4 years ago

Thought about that too for a while, we would have to add a "Overwrite Chip-ID" option in WebUI.

Chip-ID is set in https://github.com/opendata-stuttgart/sensors-software/blob/master/airrohr-firmware/airrohr-firmware.ino#L4226

As for Security/Integrity concerns: I could easily fake my id by compiling and flashing the Software, it seems theres no protection against this stuff. Would need an API-Key or Login. Or simply trust users not to do bad stuff.

But with OpenSensebox you can just specify your ID without any protection too.

Whats your thoughts on this? Im open for creating PRs to add API-Keys or something in the APIs or just do an overwrite field.

RikDrabs commented 4 years ago

It is indeed easy to put a fixed Chip-ID in the source, recompile & flash, but this has the disadvantage that automatic updates are not possible. If it would be my own sensor at home, no problem. But user's sensor can be tens of kilometers away, and i don't want to run around only for updating those manually. So an "Overwrite Chip-ID" option in WebUI seems the solution for this problem. There should be some form of protection against accidentally changing the Chip-ID, it is important that no two sensors have the same Chip-ID !

It is also important to have some form of protection on the entry of Chip-ID's in error when registering on meine.luftdaten.info, to prevent problems with Chip-ID's from other not-yet registered users. I suggested previously to check the data communication from the Chip-ID during registration: 1) Is this a previously unknown Chip-ID, and 2) Is there data-communication from this Chip-ID. If both conditions are met -> OK, register. If not, do not register.