Make a apt-get package

11 posts / 0 new
Last post
Emil's picture
Make a apt-get package

Is there any progress in making a package (apt-get) for hivetool?
I will try to contribute here and found the following pages that can help set this up

source control

Great idea. That will make pushing updates a bit easier

I think a step in this process is putting the code on github or an equivalent. I now there is a github repo but it's outdated. A well managed sourcetree will help in bundling new releases and see what's in there.

2nd for GitHub!

2nd for GitHub!

Easy to get the contributions going then.

Emil's picture
Agree on Github

I agree with you with Github, I haven't used it myself, but found an easy startup guide here

apt-get package or image

Nudge Nudge.....
A unified package with Hivetool and HiveControl behaving nicely together would be great.
The sensor reads may need coordination, perhaps do one sensor read and populate both databases?
I'll do my best which will likely be an image with Raspbian and all the packages ready to burn to micro SD.
I'm hoping we have a new Hivetool release to start with though.

Adrian Ogden

Paul's picture
apt-get package

I would love to have an apt-get package. I would love to just get current hivetool code on git-hub. I don't not understand pull requests, forking and merging. Sorry, I know I need to learn, just not enough time.

I don't think there should be a unified HiveTool-HiveControl package. I think for now they should be kept separate. I think other developers will develop other code and trying to roll it all into one big package is bad. I would like to see a bottom layer of sensor reading (and maybe logging) code, a harware abstraction layer(?) that would make it easier for others to develop GUIs and different data analysis and presentation code. They could just grab the data through APIs and be able to focus on the UI.

Nate's picture
Clarify the role of HiveTool and HiveControl please

Now I'm confused the roles of the two software packages are not really defined.

I'd seen references to HiveControl on this site, so I installed HiveControl off of Ryans github site this weekend, thinking that this would be an acceptable way to get updated code - it seems like he's pretty actively updating the code on his site.

Is there a relationship between HiveControl and HiveTool

At first I thought they were two functionally differend HiveTool modules - ie one was doing sensor stuff and the other was doing data aquisition and forwarding, but now I'm thinking that they're separate but doing a lot of the same basic stuff. When I compare my HiveControl build vs the HiveTool manual build procedure... it seems to have a lot of the same packages that HiveTool manually installs. So do they both run on a HiveTool Image or am I totally turned around?

If they're both on the HiveTool... wouldn't it make sense to install Hivecontrol first since it has already scripted the install for 90% of the device drivers and web server?

If HiveControl is installed... why is HiveTool separately reading and storing sensor data into a separate database?

Matt's picture
One or the other?

I downloaded the latest 9/29/16 software image for Pi I got the image expanded and booted with no problems, but I was confused over why there was hivetool and hivecontrol. There is a lot of leftover/unnecessary items in /home and cron that are confusing. This is my first experience with any of the software here and there is no description I could find of the purpose of hivetool vs hivecontrol. It seems like the image should have one or the other installed for simplicity. I agree with Paul that building one image with everything installed is a bad approach. A first step might be to offer separate images for each tool, and a second step could be a scripted approach to install the tool of choice.

After sorting it all out I went the route of using only HiveControl and removed the webserver and cron config for Hivetool. This simplified the configuration and made it easier for me to succeed in getting things working. I setup phpLiteAdmin for the HiveControl database and fixed a few problems with the Apache install. I really like where the system is at now with the exception of the clutter left behind by the hivetool install.

One or the Other?

I apologize for the shortcomings for not explaining the relationship and rationale of a combined image.
My primary intent with HiveContool was to facilitate the layperson beekeeper to to get a system up and running with minimal guidance.
I have been demonstrating at bee clubs which has sparked a lot of beekeeper interest, I want to make systems available with minimal effort.
I could have loaded HiveControl or Hive tool but each have areas that are superior IMHO.

As a non-programmer I am unable to efficiently unify the configuration, data acquisition (sensor drivers) and databases.
Ultimately I feel it be in the project's best resource interest to unify but it will require effort, coordination and follow through.
I have observed alternating and independent HiveControl & Hivetool development, in my opinion it will be more efficient to coordinate and unify the sensor reads (data acquisition) and databases to prevent development replication and other problems like dual uploading.
I believe it's good that the user can choose one user interface or another without exclusion as each has different attributes that may be more desirable for one's needs.

Apologies for the messy state of the image, hopefully in time and given the resources we'll clean it up.

I can't speak for everyone and don't mean to set any particular direction by these comments.
As an open source project I hope that we can strive at a quorum in our direction.


Adrian Ogden

Matt's picture
features matrix?

Would it make sense to put together a features matrix to compare hivetool and hivecontrol? For a new guy like me there is no way to figure this out without a lot of hours pouring over each product making comparisons.

I simply wanted to share my experience as I worked through the process with this software image to provide feedback for growth. I come from a systems admin and integration background. I am not a programmer and cant contribute to the project in the regard. I think it makes tons of sense to have a standardized approach to data acquisition and storage as the basis for the system. On top of that you could layer on alternative UIs and analysis tools as needed. This would pave the way for automation modules for installation and upgrades.

Features Matrix

We have been behind the curve in documenting, a features matrix is an excellent idea.
I can envision categories; setup, configuration, sensors supported, database, cloud upload, GUI attributes, reports, trend graphics, analytics, alarming, text, email, communication (wifi, bluetooth, cellular), platform (Pi3, PiZero, BLE, PC, Mac, Linux).

We could also have static images of the various screens one has access to, or even an online Pi monitor anyone with login privileges could experience using RDP or ?.

Adrian Ogden

Log in to post comments