Closed aviateur17 closed 1 year ago
This is cool for now. As I've mentioned, I want to disassociate READING_ID and network IDs in the future, partially because when we add functionality to change the READING_ID over-the-air, we'll run into a lot of confusion. Another type of UUID would be preferred, maybe even borrowing from the MAC address if it is an ESP.
I want to disassociate READING_ID and network IDs in the future, partially because when we add functionality to change the READING_ID over-the-air, we'll run into a lot of confusion. Another type of UUID would be preferred, maybe even borrowing from the MAC address if it is an ESP.
Sounds good, shouldn't be too difficult to separate when the time comes.
From Discussion #65
In FDRS_Sensor the readings have a READING_ID in fdrs_sensor_config.h which is designed to be modified by end user for each sensor. However, there is also a LoRaAddress configured in fdrs_sensor.h which file is not designed to be modified by end user. Therefore each sensor would have the same LoRaAddress which is not desirable. Can we make READING_ID part of LoRaAddress?
This PR makes READING_ID part of LoRaAddress so that user does not have to change fdrs_sensor.h