-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethink Device, Kit, Component, Sensor #241
Comments
Coming back to this issue as well, this means we can create also endpoints for |
Hey Oscar, a couple of questions on this, which we can discuss tomorrow:
We'll chat it through tomorrow, but just wanted to give you a heads up :-) thanks! Tim |
One little update on the above - we do indeed have two sensors which take different equations depending on which kit they're used as part of, so will need to dig into why, or find a way of dealing with this!
|
These are the sensors in question:
|
(notes from chat) keys: should always be the same. |
(more notes) - leave 'kits' with an OPTIONAL relation from devices, for name and description. Move components relation to devices as agreed before. |
Notes from meeting. Sensor_map needs to be maintained to map between sensors and cassandra timeseries. However, the key for a sensor varies depending on what kit it is a part of (It shouldn't, but it does - theses aren't actual semantic differences):
THEREFORE - we allow for an inheritence mechanism where a That way, the Kit concept can be dropped entirely - the name and description can be thrown away, and the name reconstructed from the device hw_info. Does this sound about right @oscgonfer ? |
It does! Thanks for the detailed notes. |
Now that we are working on all of this, it would be good to understand some extra points (and maybe clean them up if suitable). It seems that we have quite a few timestamps that represent similar things in different places, as far as I noted: Device Object
Device.data
Any insight on why so many aliases? |
Hey hey @oscgonfer - I'm close to a first draft PR to go over when we're back at the end of August, but just wanted to make you aware of a small hitch in our plan (it might not be a big deal, but then again, it might be). I've discovered that the order of the columns in the exported CSV of a device's readings is defined by the It seems like it might be an unneeded extra bit of complexity (especially given the original Let me know what you think! Thanks, Tim |
Re the dates - that can almost definitely be simplified. created_at and updated_at are rails defaults, and last_reading_at is ours (and is obviously useful). added_at, i have no idea, and at a glance seems to have an inconsistent definition across at least two different places. Perhaps we can get rid of it? |
Hey Oscar! Please see a draft PR here: #246 - there's a few small bits outstanding that I've detailed in the description, but i think the bulk of it is done and working. I'm going to be away from next week 'til the 1st of September - I'm not sure when you're back, but if you happen have any questions before then, i may not be checking Slack, so drop me an email (or I guess a comment on here), otherwise we can catch up in September! Thanks! Tim |
Hi there! So I am writing from the US now, that's why you will see this comment in weird hours... In addition, we should use ISO8601 for the datetime format. At least, I would suggest that the header would go like in here, which would imply unifying the Long story short:
|
Let's talk in September! Have a good summer break! |
Notes:
|
Discussion now moved to PR. Let's keep it there to avoid duplicity: #246 |
Merged! |
This issue is to discuss about potential changes on the data models we currently use on the API.
Currently
There are two issues:
This is an important topic to improve, because new hardware versions will immediately duplicate those 18 kits just by simply changing the urban board. This will create an unmanageable amount of possibilities that users will need to navigate through from the Advanced kit selection.
Proposal
In a first stage, the proposal would be to change the
components
relation to be directly withdevice
instead ofkit
, and modifycomponents
to already assess the problematic ofmeasurements
orsensors
.kit
would disappear as it is right now. In this concept,device
components would not be created based on a pre-defined blueprint (or kit), but based on the hardware publications directly, which would pass through thereadings_controller
(or whichever) creating the components for the found sensors on the posts if they exist in the sensors table. New posts, with additional sensors connected, could dynamically be added with this approach. However, further discussion is needed to review what happens with thesensors
/measurement
issue.In a second stage, the proposal is to consider the duplicity of sensors in the same device (aka
the mux
). This would mean we send a uuid of sensor on the hardware (based on sensor model and location) which we need to "parse". This could use a new propery incomponents
which specifies an uniquelocation
for eachsensor
so that it can be uniquely located.The text was updated successfully, but these errors were encountered: