thanks for mentioning the Hiveeyes project. I’m one of its members and the main author of the backend data acquisition and -visualization system Kotori. Feel free to ask me anything.
We are happy to provide further information as our system might be interesting to the TTN community for many different data acquisition tasks in the field of environmental monitoring and beyond. As it integrates InfluxDB, Grafana and more FOSS components in an elegant way, we also posted its description to the topic LABS - Store and visualize data using InfluxDB and Grafana.
I will try to respond to your list of specific requirements in the next post as good as i can.
thanks for outlining your imagination of a perfect system. It is very similar to our goals, let me get more specific along the lines:
As this is also very important to us, it was one of our main goals from the very beginning, see also Goals — Hiveeyes system documentation 0.9.0 documentation. We don’t make compromises on that: All system components are and will be based on open source licenses.
While looking at TTN since about a year, we just recently made some little efforts to push things forward, see also "Richtiges" LoRaWAN Gateway - Funkinfrastruktur / Wireless infrastructure - Hiveeyes. However, we are already transmitting measurement data from remote sites using plain LoRa (using a HopeRF RFM96 transceiver module without LoRaWAN).
While you can always host the FOSS system components on your own machine, we also operate a shared platform free of charge for the beekeepers community, see also The Hiveeyes system documentation — Hiveeyes system documentation 0.9.0 documentation and Grafana. While not everything is as polished as a commercial IoT platform yet, you will gain way more flexibility, features and peace of mind through best-of-breed FOSS components. When there’s reasonable demand, we will think about implementing adapters to Thingspeak or Opensensors.io to further grow the ecosystem and improve the versatility of the system.
As said, we are happy to receive further suggestions and answer any questions which might come to mind. Also feel welcome to join us at the Hiveeyes community forum! To get more precise: The system was not designed for “us”, but offers a generic infrastructure for the whole community of beekeepers monitoring their beehives.
Thanks! At the moment the prototype is running on an atmega328p as used in the arduino’s.
Plans are to upgrade to another microcontroller, I have experience with the atmega1284p from other projects or I might chose a newer cortex M0 variant.
I don’t have plans to make it commercial or open source until everything is as it should.
I’m using Si70XX sensors for temperature & humidity. Low power, voltage down to 1.9V (correction: not 1.8V that I thought…) and small enough
There are no DS18B20 used, these need indeed >3V to be able to work.
@amotl Hiveeyes is a great platform as I can see! Much documentation etc.
My hardware setup is similar, I’m using an RFM69 wireless link to connect the BeeMonitor to an custom arduino based receiver that feeds data trough UART to my raspberry pi (not over USB). I was already running Domoticz so I also used it for the BeeMonitor. It works but it isn’t ideal beedata, I really need a new software platform.
So it might be a good idea to modify & upgrade my hardware so it can be used for Hiveeyes. My goals are to keep it small, universal & low power to keep it running for years. Without battery charging, solar panels, …
Thanks for acknowledging. Yes, we put quite some effort in it to make it easy for others to adapt it to their own requirements and also to encourage beekeepers to join us and share the measurements with each other in the spirit of open data. When it comes to discussing specific observations in a collaborative way, it’s really fun!
Cool! The USB connection in our case is also just an UART on the Linux system side, so the setup is almost identical. How do you currently read and process the data on the Linux system? We are currently using a little Python daemon (see BERadio ff.), which decodes the radio message payloads and publishes measurement data in JSON format to the MQTT bus. We are happy to integrate specifics of your radio message format if you share some more details.
I bet the modifications required will be very small. We will be happy to serve your needs and requirements and even more if we could get you on board. May i ask you to join our community forum to sort things out? We can link the conversation to this discussion to enable other people to follow it.
Last but not least (to make things a bit clearer maybe): All system components are available as Debian packages for the armhf architecture, so operating the whole system on a Raspberry Pi is possible. Some of our members are already doing this. Optionally, the data can be shared with the collaborative platform by connecting the MQTT brokers to each other.
Just get back to us if you have further questions!
With kind regards,
Andreas.
P.S.: One of our members who joined in January came to us with pretty much the same intentions. He is also using a Raspberry Pi, however not as a gateway, but with sensors directly attached. Enjoy reading:
for getting started with the collaborative platform, you might want to have a look at the documentation about data acquisition, either using MQTT or HTTP. When publishing data to the “testdrive” channel, the measurements should appear at the “testdrive” Grafana dashboard. If that works for you, please get back to us for assigning an unique “network” identifier, i.e. your personal realm.
This is a fascinating thread. Another sensor you might consider is one or more accelerometers built into the frames. Some research has already been done on this, though quite a bit of data analysis is required. However, it potentially contains information about the state of the hive we can’t currently obtain.
@amotl, I need some time to get started with it. There won’t be much hardware changes required for the switch to Hiveeyes as I’ve seen in the docs. All can be done is programming/software. For myself I want to add more options and add the option to connect a scale (load cell based) in one device.
I’m only interested in collecting beedata as follows:
Inside temperature from the hive core
Maybe temperature/humidity sensor in the cover, still inside the hive
Outside temperature/humidity measured (sensor in the BeeMonitor, optional with external sensor)
Beehive weight
Some other already included features are:
Dipswitch to preset beehive ID (allows up to 16 devices in one network without software changes)
Dipswitch for “wakeup” interval (can be preset on 15 min, 30 min, 1h or 2h)
Wakeup button (manual wake)
RGB led (visual feedback)
Buzzer (sound feedback)
RJ12 connectors for sensors
For me that’s enough. But suggestions, features I’ve missed, … are welcome!
Sounds good. What hive scale are you using? Is it a diy design? Or a commercial offering?
It also increasingly seems like the functionality you describe above seems to be that best suited to the bandwidth constraints of LoRaWAN. Could become part of a ‘semi-standardised’ opensource ‘hiveeyes’ box, using the hiveeyes backend.
Having said that, the audio analysis & accelerometer stuff also very interesting. I wonder if that should be tackled as a separate / side project ‘buzz box’ or similar. It seems that box would need more processing power, and therefore bigger solar /power requirements. There is no reason that the ‘buzzbox’ couldn’t pass swarm alerts to the ‘hiveeyes box’ for transmission over the network.
Perhaps data from the ‘buzzbox’ could be saved as sonograms to Sd card to be uploaded every couple of months?
How would you manage sending data to multiple storage locations, via whatever network/protocol is available? I imagine a “module/function” for each available network (WiFi/Ethernet/LoRaWAN) and one for each of the data storage locations, then a central sort of broker to send out the data. Sorry for the noob questions - I have something similar in mind, but not really any clue about how to go about it.
This is a great thread, and covers a lot of ground we’ve been developing ourselves at OSBH. We are about to release an open source board / iOS & Android app monitoring system that includes:
Internal / external temp & humidity
Anti-theft (internal accelerometer)
Atmospheric pressure
Solar power
Wifi connectivity (GSM coming later this year)
Most excitingly – high sensitivity audio recording and analysis
Our goal is to monitor how colony health translates to audio signals from the bees buzzing, as has been eluded to by multiple peer reviewed studies on the subject…and so the device is called the BuzzBox ;-). BuzzBox will take periodic samples of audio and send them to our server where a machine learning algorithm we’re developing will learn correlations between these signals and various hive states. The audio will signal push notifications to warn you of impending problems within the colony.
I am not on the “developer” side of the project, so I cant get to specific on sensor varieties etc. but I have asked our team to put up some clear documentation in our forum and will share a link here asap for everyone to take a look. If you’d like to join in on what we’re doing, we’ve allocated additional inputs on the sensor so it can be hacked / added to by others…we’ll be crowdfunding this in a few weeks time!
Will report back soon, but please have a look at our site / documentation / forum if interested!
Hi Tristan, thanks for your message, Exciting stuff… Can’t wait to see it.
It would be interesting to know if your server side stuff will also be open sourced?
LoRaWan has many advantages, but bandwidth isn’t one of them.
So it might be interesting to grab your latest algorithm at the start of each season and run that locally on a Rasberry Pi or similar (if the hardware is up to the job)
The Pi could then send a simple ‘swarm alert’ message to the LoRa board for forwarding/ mobile alerting. I realise you wouldn’t have the latest algorithm, but it might be a good compromise for those of us intending to use LoRa.
Hey @sam-1 – we’re using the Particle processor and I believe we do run the algorithm locally. As well as uploading the sample to our servers for further analysis down the line.
As for server side – yes the plan is to have everything open source – the data, the algorithm etc. etc.
Again, I am not the technical lead on this, so I can provide too many details or speak to this LoRaWan suggestion. Will get back on further info soon.
The scale would be a home made one based on a single or multiple load cells with the popular HX711 converter. As a said before it’s work in progress.
Things as audio analysis, accelerometer don’t work very well with low power systems and will need a bit more bandwidth & processing power. For myself I see little use in gathering data like this.
I’ve had very bad experience with solar panels, battery’s, etc… in temperatures below freezing point. It’s just not reliable enough for me, something that’s installed and stays online for years is what I need!
We wanted to share access to some early discount BuzzBox sensor kits – you can secure these on our website www(dot)osbeehives(dot)com – (the forum wont let me post the link for some reason)
We have also written up our hardware and analysis documentation, which you can access by clicking the “documentation” link on our homepage.
We hope you will consider joinging the BuzzBox network
May i ask you to join our