I’ve been reading these forums for perhaps 18 months and am ready to move forward.
I’ve settle upon the 8266 Pro Mini 3.3v 8mhz with a DS3231 RTC, located near the load cells to provide temp adjustment. I’m intending on powering only via 3.2v LifePO4 battery - adding solar if I really need to.
I want to connect the 8266 to a LoRa wireless radio 1276 to communicate to a LoRa nano gateway which in turn will communicate to the outside world via a NB1 interface and using MQTT as the protocol for on forwarding to a virtual server.
My question: Is LoRa ‘over the top’? Should I revert to WiFi? Distances between hives and the gateway may be up to 500 mtrs with vegetation between.
Using Google Translate I’ve been able to understand much of the forums Which firmware would be most suitable to adapting to my needs? Am I on the right path?
Welcome Mark.
I think 500 m over WiFi is a bit too far. With me I already have to struggle with 150 m in vegetation and wet weather.
I now have something similar in mind.
Because WiFi and energy supply are not sufficient at my other locations.
If I will use a CubeCell HTCC AB01 there is even a solar battery and LoRa on board.
I’m currently in the process of writing a provisional firmware for it.
I will use:
Heltec CubeCell AB01
bme280
NAU7802 (alternative HX711)
5x DS20B20 (1x outside, 5 x inside.)
I looked at the Cubecell but [put it to one side on account of cost. Ultimately I will have 150 - 200 hives probably located in different regions in groups of 30 to 50. Therefore I’d also have 4 or 5 FiPy gateways which would move with the hives as they migrated to follow the nectar.
However, perhaps I should reconsider the Cubecell, as it does wrap a lot of functionality into one unit
For the ADC, I had settled upon the red coloured HX711.
I too was looking at measuring the temp across the brood box - but only in a subset of hives. I was thinking of using a separate unit for this specific purpose.
I am also looking to include a couple SW-520D vibration sensors to give an alert in case of the hive being knocked over by an animal or theft.
Micha, I’d be very interested in following your progress!
What board are you using? “8266 Pro Mini 3.3v 8mhz” sounds like an ESP8266 (perhaps Wemos D1 mini Pro? but it has 80/160MHz) but also as an Arduino Pro Mini?
(1) In case you are using a Pro Mini: The old Arduino chips are too small to drive the newes MCCI LoRa lib and you have to continue with the old deprecated LMIC lib. (2) In case using the ESP: The ESPs seem to have a problem while forgetting everything over a deep sleep phase, so OTA in TTN V3 seems to be a big (unsolved?) problem with the ESPx boards. For both issues see https://www.youtube.com/watch?v=mFprG2UuHrA&t=421s
Along this power saving post for the D1 mini from Renzo Mischianti the deep sleep current for the D1 is 6 mA, I fear a bit too hight to use it in deep sleep without a switching MOS-FET. Have the deep sleep power consumption in mind especially in case you have not planed to use solar support.
My recommendation would be: Build the nodes as “normal” TTN nodes so you can use existing infrastructur – public TTN gateways – in case it is around. So you can use standard hardware and software for the gateways and provide TTN to your local community.
What is the reason for single channel gateways? The price or other things and how will you operate them? Always ON or combined with the nodes in parallel wake up and sleeping phases to save energy?
Btw nice to have you on board and welcome to hiveeyes as “active” member! ;-)
I am also working on a LoRa connected hive, which will be my second version (the first one is around a Raspberry powered by solar panels which control 6 hives and uses a GSM connection. Works fine but too many cables).
Make sure you check the work that Lopes Parente has done recently (this summer). It’s a LoRa application example that uses the MCCI LoRa library, which makes the implementation incredibly easy.
I am using an Adafruit Feather M0 board with LoRa radio included. If you are living in a geek friendly region, there should be a TTN gateway available around to collect and transmit your data. For integration, I am using a python program (using paho MQTT library) which gets the data from TTN and pushes them to a google sheet file. Works fine (see a copy of my dashboard: StHugues.pdf) but I’ll also try the hiveeyes way of integrating which I didn’t know before (influxDB & Grafana). Even if I have done some work on temperature compensation, I haven’t implemented it yet. Need to better characterise the load cells, which I intend to do shortly with the new set-up.
BTW, I have never heard about NAU7802. Is it any better than HX711 ?
Cheers
-Henri (from Grenoble/France, the place where LoRa was invented…)
Yes, it is better, it runs on I2C and so far has no false spikes due to timing problems. It also has 2 full (128Gain) channels and reads very fast.
The main disadvantage is the high price of breakouts and poor availability. You can also buy loose ICs in DIP16 or SOIC16 housings from Digikey for less than 2 €.
I made a circuit board here some time ago because the price for the finished breakouts was too exaggerated for us. GitHub - MKO1640/NAU7802!
Here ist my current test Environment, with DIP16 NAU7802
Hi Clemens and thank you for your considered input.
Am unsure now if I have purchased the Pro Min or ESP. I will need to look in my box of tech next week as I am 4 hours drive away tending hives (our spring here in AU).
The reason for single channel gateway is primarily cost…and I don’t think I need 8 channels to look after approx 30 -50 nodes at each location.
There is no LoRaWAN infrastructure available and in some cases also no mobile phone recption (I think you call them 'Handy" ? ) in some of the locations so I’ve selected the Pycom FiPy as it has NB1 which should work anywhere the hives will be located.
The gateway(s) will always be on - I don’t mind provisioning solar and battery to suit in this case.
With issues you describe for both boards, I am now more strongly leaning toward the Heltec AB01, despite the cost.
You can get the AB01 very cheaply, directly from Heltec.
However, the shipping costs are very high, which means that it is only worthwhile for a certain number of items. Taxes must also be taken into account.
But at the moment = “out of Sock”
But first I would only get 1-2 somewhere else and see how you get on with them.
One problem with these is, for example, that they do not have an EEprom on board to save the settings of the scale.
Instead, there is a user space in the flash memory that can be used for this.
But there is also the option of adjusting the offset and factor for the device settings in the TTN console. And then use this when decrypting in the payload formaters.
At the moment we – swarm.hiveeyes.org – have no database to save configuration variables such as offset or factor for the HX711. It is possible to implement it in the panel’s JSON on a single panel but we have no location for that atm. Setting up a database would be no problem but I’m thinking on a user friedly opportunity, like a form in Grafana, to input variables.
I would store such thinks always on the node. So you have always kgs in your data stream and no raw values that get usless in case you lose the config variables. We need always individual variables like node ID or TTN stuff, so we need a mechanism to store varialbes on the node’s EEPROM (or in the code) anyway.
I understand. Manually setting the settings in the firmware for 150 nodes is a lot of work.
PlatformIO and VS-Code will certainly be able to do some of the work. For example, automatic generation of the device ID during flashing and parallel storage in a table would be possible. You could then get this via the TTN-CLI at thethings.network. In order not to have to manually register every device there.
The calibration of the scale can certainly not do this, as each load cell, HX711 combination requires its own individual setting.
This would be possible either via the serial interface with storage on the node, in the TTN console before forwarding or before the final storage of the data on the server (e.g. swarm.Hiveeyes.org). But that will probably be the most complex variant that it has to be implemented.
Exactly my thought. The whole thing is even more important with several 1Wire sensors than with the HX711. If one of them should fail, the node would otherwise not know which one has failed, since an individual identification cannot be sent with TTN.
Which firmware would be most suitable to adapting to my needs? Am I on the right path?
) in some of the locations so I’ve selected the Pycom FiPy as it has NB1 which should work anywhere the hives will be located.