New ID's in the software config

8 posts / 0 new
Last post
Nate
Nate's picture
New ID's in the software config

Hi,

I see a few new ID's I don't recognize from the previous version

Hive ID
Yard ID
Beekeeper ID

Do I just invent something, or is there a procedure to establish these ID's?

The configuration screen says to refer to the documentation to get these, but not really sure what document it's referring to.

Paul
Paul's picture
HiveTool vs HiveControl

These are used by Ryan's HiveControl Software, not Paul's HiveTool software. Sorry for the confusion. I think you have figured this out but I will respond to the rest of the posts and try to explain.

wwfoste
Difference between HiveControl and HiveTool

I've seen these two discussed. I understand they are 2 different pieces of software and one is on Google drive and one on Git Hub. But what are the actual differences between the 2?

Ryan
Differences?

Hi,
So I wrote HiveControl to augment and improve on the great work by Paul. Originally, it was called hivetool2, as we leveraged most of the original code for Hivetool. The original idea was to implement some of the open asks on the developer pages...
1. Wanted a quick easy way to install without having to download an image everytime.
2. Wanted a logical directory structure
3. Wanted to update the charts to something more modern (highcharts)
4. Wanted to be able to support local weather stations
5. Wanted the option to select/configure different instruments
6. Still wanted to be able to share with HiveTool

To answer Nate's question:
HIveID = Not a new field, you just may not know it existed on Hivetool. Every hive needs a unique ID. We just expose it in HiveControl. We were working on a YardController (allow someone to see multiple hives they owned, and ultimately be able to use parts for Hivetool.net) - We are crafting an Web API that allows web posts to a controller, and part of the authentication would be your unique HiveID.
BeekeeperID - Part of ensuring uniqueness - Allowing us to track which hives you should see when logging into higher upstream systems.
Yard ID - for the enterprising beekeeper who may have multiple yards with HiveTools monitoring each.

You can leave all at 1 for now.... or change to whatever you want.

Ryan

Ryan

Nate
Nate's picture
Thanks for HiveControl info

So, if I'm using the HiveControl version... is this forum still applicable to the software portion of the hive controller or as the name of the forum states... is this for HiveTool alone.

I like the idea of a yard controller. it seems logical.

I would think only a yard controller would really need ambient weather data.. not every hive controller.

Also a yard controller would be a logical home for a 3/4g modem to live and share as a hotspot to the rest of the yard - I'm thinking of deploying some hive monitors up at my cabin next year and will need a modem since my wifi can't quite reach 90 miles north.

Yes to the web service. I'm trying to pull this data into another system, and if we could easily define a custom web service endpoint... I think that would be a really slick way to send my system data. If you add this, try to make it possible to define multiple web service endpoints. Alternatively I am looking at running. Security would need to work with a windows machine at the other end for me. It sounds like the XML would contain everything I would need to enable automatic creation for data streams and models. I'm looking alternately at using an OPC-UA server for raspberry PI, but I'd still need to define all of the data to send.

Paul
Paul's picture
Forum is not just for HiveTool alone

Just my $0.02 worth but this forum (and HiveTool for that matter) is only limited to technical aspects of monitoring biological systems and the environment. My long term goal/big picture goes beyond just monitoring honey bees. I believe that there are plenty of stressed systems from frogs to bats that would benefit from real time monitoring and analysis.

I am delighted that Ryan has developed open source code and I hope that other programmers with different insights, experiences, needs and goals will also develop and release code. I think it would be cool to have a dozen or so different interfaces or GUIs for the user to choose from. I believe in letting the market place have the final say. (It is my diabolical plan to some day pick the best features from each package and write the ultimate monitoring system.)

I would like to see a "hardware abstraction layer" (for lack of a better term) developed that would consist of sensor drivers and methods to access the sensor data. This should make it easier for other developers to concentrate on data analysis and presentation without having to deal with the hardware.

This is probably the wrong place to post this - maybe I should develop this thread into an blog topic. To get back to your original question, the "Hivetool" code has a contact_id that is probably similar to Ryan's BeekeeperID. It exists on the RasPi SQLite "Hivetool" version but is only used in the hivetool.net/.org database to link the hive_parameters, contact and hive_data tables so one contact can have multiple hives.

Nate
Nate's picture
Two comments

I see your plan now Paul... you wanted to be involved with development of the first bat scale and frog temperature probe for their natural habitats.

As far as the BeekeeperID - Developers should really try to keep consistent - problems arise when there are multiple variable names, and schemas are used for the output... what do external systems do when one program sends hive data with BeekeeperID and another one has contact_id. How that variable gets used by different developers can change, but ideally there really shouldn't be two different variants of the same variable.

I realize this is an open source project so every developer can do what they want, but irregardless of if you're monitoring earthworms, greenhouses, or bees... the common schema can and should stay the same

Ryan
BeekeeperID vs Contact_ID

So, a little explaining on my part - I do agree in standard naming conventions, but you'll find you can't design for EVERY eventual use of the monitoring platform in the first revisions. I chose BeekeeperID, to differentiate between ResearcherID (as I was coding an interface for Open access to the data for Researchers, but wanted to track them differently than BeekeeperIDs.... The key as well for the central system is to publish the data fields, and any "add-on" product can perform a translation before sending. For example, none of my hives are running the hivetool code base, but they translate the data we collect into HiveTool so we can share our data.

Ryan

Ryan

Log in to post comments