You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A different way of handling the sensor implementations was started to make things easier and try to homogenize the whole structure. Ideally benefits of this new approach (in branch https://github.com/fablabbcn/smartcitizen-kit-21/tree/channels) are:
Sensor objects are created in runtime, not consuming RAM memory in principle
Indifferent if the sensor is on the Urban Board I2C bus or on the Aux Port I2C bus
Cleaner and more homogeneous implementation
As a first step, this new implementation would keep the same sensor ids as usual, and test the new data model, fablabbcn/smartcitizen-api#241 with the current implementation or this new structure.
Further down the line, the idea is to send sensor ids with a "hash" composed of different variables to be documented, such as the current sensor id, and the bus in which the sensor is located. This would allow a mux to have duplicated sensors and each of them be uniquely identifiable.
The text was updated successfully, but these errors were encountered:
A different way of handling the sensor implementations was started to make things easier and try to homogenize the whole structure. Ideally benefits of this new approach (in branch https://github.com/fablabbcn/smartcitizen-kit-21/tree/channels) are:
As a first step, this new implementation would keep the same sensor ids as usual, and test the new data model, fablabbcn/smartcitizen-api#241 with the current implementation or this new structure.
Further down the line, the idea is to send sensor ids with a "hash" composed of different variables to be documented, such as the current sensor id, and the bus in which the sensor is located. This would allow a
mux
to have duplicated sensors and each of them be uniquely identifiable.The text was updated successfully, but these errors were encountered: