Sensor Kits
trizcs — 2015-02-01T11:49:31-05:00 — #1
This topic is continued from a previous conversation in the forum.
The manual HiveLife data entry app and the OSBH sensor kit may benefit from exchanging data, possibly to inform an OSBH data algorithm. The intended result of this would be to teach the OSBH algorithm how to detect more subtle variations in the hive via manual data entry by HiveLife app users.
jakub — 2015-02-01T13:32:53-05:00 — #2
Basically we have quite similar idea @brianzable. Although it may vary in detail.
Actually by an app I didn't really mean a standalone solution. Rather a web interface to the system (whatever it will be). Such strategy leaves a really large field for collaborators to create their own data interaction solutions which will work within the same OSBH ecosystem. In my opinion the center of everything should be a core system. Frontends should just connect to it to allow data interaction. Also data from the sensors should go directly to the core system.
- I wouldn't worry about the engagement at this point too. At this moment the participants should be considered strongly aware and engaged.
- The weather data should not be a problem. The system can query weather services whether there is an inspection or not. It would just match the inspection date with an already collected weather data sample frome the area where hive is located. The best case would be if there were additional weather sensors in an apiary.
- My opinion on data accuracy is just the same as yours. There are actually two ways of solving the problem. One is to make the system available exclusively for OSBH sensor kit owners. This would not really be correct for a community driven project The other way is to introduce segmentation. OSBH kit owners would fully participate in the project as both data providers and beneficiaries and the DIY'ers would just benefit from it's features. This is just an idea that could do good for the project until there will be a lot of data to process. In terms of data quality I would personally prefer official hardware requirement.
The amount of data can be a problem in terms of cost but without it there will be no investigation possible. Actually it will be possible from the technical point of view, because there are algorithms that can be trained on the stream of data and you do not really have to store that data anywhere, but in such scenario users can possibly be disappointed with lack of access their contribution. But a much bigger disadvantage would be the inability to process the data with other possibly better algorithms in the future. That would be a real waste.
I think what should be done in first place is the data layer and the api as well as the desktop fronted design.
ron — 2015-02-02T06:38:55-05:00 — #3
Hey @jakub and @brianzable!
Looks like we're going into a new team here. Thanks Jakub for your suggestions and ideas. I really like the idea about a core (raw) database with individual interactions/interfaces to that. In that way we might be able to include the HiveLife project data and data from other documentation software more easily.
Also with some of your issues brianzable I think it helps alot using the sensor data. Jakub mentioned already the weather issue.
About the ease of use of the APP: Once that people installed the OSBH sensor-kit in their hive I think we could make adding notes and records way more easily by providing automated functionality (depending on: which hive was opened, conditions inside the hive, time of the year, weight of the hive - the APP could already suggest some answers about what the beekeeper has done - usual inspection, swarmed bees, taking honey.. etc.)
In that way recording data could be even fun and would motivate more people doing it. I agree totally with Jakub that we need a way to connect our sensor data with some information about what actually is going on in the hive so we really need the data you're collecting with your app brianzable.
@Jakub @CamJones What do you think about starting a team working on data layer, api and frontend design together? As far as I know our approach until now was to include our data into the Smart Citizen Kit database. But actually we might need something more suited to OSBH project - especially when we're trying to include manual data records. And it looks like you have some good ideas about that.
Just a brief information about me and my part in the project:
I'm a 24 year old student doing my internship in fablab barcelona. I'm working full-time and most of my time on the OSBH sensor kit. Right now we're prototyping the whole sensor kit with the spark core. Later we might change the hardware to the base board from the smart citizen project. We're running temp, humidity and audio frequency sensors until now. The idea is to add weight sensors and a bees in/out counter in the next weeks and start field alpha tests with the sensor kit.
We will need to have a database and the code for uploading the data to be ready at that point (I think around end of this month).
What do you think about a short skype meeting this week to get things started and to get to know each other briefly? I'll send you a private message.
best,
Ron
trizcs — 2015-02-02T10:07:03-05:00 — #4
@caleb - I know you work with an engineering firm, do you see any way to plug into this conversation?
@coloradobum @hognala - you will probably find these ideas interesting - care to get involved?
aaronm — 2015-02-02T11:59:38-05:00 — #5
@ron Hi Ron,
This looks like good momentum. Let's get a functional spec. started/outlined, and we can start mocking up the user interface. Will you make that a goal for the upcoming meeting? Once we have that, we can manage interfacing with the general community of users to learn more about their user experience needs.
brianzable — 2015-02-02T21:27:48-05:00 — #6
Hey @ron and everyone else in this thread!
While I'm not focusing on retrieving sensor data into my application just yet (I want to get something out there that all beekeepers can use), I am interested in being involved in any conversations around software to hold the data from sensors. It's definitely something I want to start incorporating later this year.
By trade I am a software engineer and work with databases on a daily basis, so I may be able to provide advice to anyone looking to jump into storing this data.
I'm down for a Skype call. What might be even more interesting if we could host a Hangout on Air. Might be fun to get a bunch of people from the community together for a chat!
trizcs — 2015-02-02T23:39:48-05:00 — #7
Excellent idea @brianzable!
Could @ron @AaronM @jonathan @jakub @coloradobum @brianzable @SenecaUPP meet online next Monday 9th at 5pm MST? If we make it a "hangout on air" it will allow other collaborators to chime in to pose questions and ideas via the Q&A function.
@BarefootBee - would be great to have you involved if keen!
Who's in?
aaronm — 2015-02-03T01:42:26-05:00 — #8
Yep I can make it - Tristan we have all of their emails - we can hit them with a calendar invite
coloradobum — 2015-02-03T10:39:30-05:00 — #9
@trizcs I have a commitment until 5ish so I might be a few minutes late, but I will be there.
jakub — 2015-02-03T13:44:29-05:00 — #10
The meeting hour might be a problem for me. Till the end of February I'm in Stockholm working at customer's office. It will be 1:00AM here. If we could move the meeting to another hour or maybe to Friday/Saturday it would be just great.
trizcs — 2015-02-03T13:57:59-05:00 — #11
Ok - would Sunday at 5pm work better for everyone?
Be good to get responses ASAP so I can start promoting this to our networks. Cheers guys!
@ron @AaronM @jonathan @jakub @coloradobum @brianzable @SenecaUPP
aaronm — 2015-02-03T14:23:58-05:00 — #12
I'm in - looking forward to it.
ron — 2015-02-03T14:29:03-05:00 — #13
For me it would be fine - even though I'm agreeing with Jakub that 3-4hrs earlier would be better for europeans
jakub — 2015-02-03T14:41:32-05:00 — #14
For me it actually doesn't make any difference if the meeting will be held at 5PM on Monday or on Sunday. The problem is the next day is a working day. But whatever.. let's do it on Sunday
trizcs — 2015-02-03T15:20:52-05:00 — #15
Oh right, sorry chaps!
Would Sunday at 11am (MST) / 7pm (CET) work better for everyone?
@ron @AaronM @jonathan @jakub @coloradobum @brianzable @SenecaUPP
jakub — 2015-02-03T16:42:58-05:00 — #16
brianzable — 2015-02-03T19:57:07-05:00 — #17
jet — 2015-02-03T23:25:40-05:00 — #18
That's 1300 PST, correct? I'll try and dial in.
coloradobum — 2015-02-04T17:21:15-05:00 — #19
I'll be at an race event on sunday at this time. Any way you guys could record the "Hangout on Air"? I'm definitely interested in this project....
trizcs — 2015-02-04T17:34:41-05:00 — #20
See the hangout page here guys - set for SUNDAY 11AM (MST)
Please hit "YES" and Google will send you a reminder - be awesome to have you all along.
We'll be putting together an agenda and sharing it on this thread for input over the next couple days so we can keep things focussed. This will be a hangout on air, so the video will be recorded and the public can pose questions and comments via IRC.
@ron @AaronM @jonathan @jakub @coloradobum @brianzable @SenecaUPP @jet @BarefootBee
next page →