Hiveeyes data in Telegram Bot

This might be of interest for those of you sending their measurements via LoRa to TTN (or intend to do so). Telegram allows to create bot channels which can be controlled over an API. In my case I let the bot subscribe to TTN over MQTT for the lastest raw data and also implemented bot commands to retrieve visualized time series directly from our Grafana instance - all written in Python.

I also extended the code to allow for sending downlink messages to the nodes, e.g. for a longer or shorter sleep period. This depends on how the node firmware deals with downlink messages.

Some rewriting would also enable non-TTN users to retrieve the raw data by subscribing to our project server.

Next milestone is to also implement event submissions via MQTT to Kotori just with a bot command on-the-fly. They have to be in JSON format, right? I’ll probably ask you here again in case of help needed.


See this example screenshot (images in (web)app get full screen and zoomable by clicking/tapping on it):

Source code


Awesome!! (This is not a buzz word here ;-)

To get it right. Is Telegram pushing the data to a certain time or do you have to request the data manually by writing /battery or /today1 ?

I’m looking for a replacement of the good old SMS so that a beekeeper is notified about the hives and has not to think about it “oh, I have to call the data”.

Nice stuff, thanks for sharing.

Looking forward!

Very much appreciated! We have been rambling about this since ages when meeting regularly back in 2015/2016 (see also Remote Konfiguration der Nodes (Firmware/Backend) and Update and Configuration Strategy for Future Nodes). Maybe let’s have a chat about the MQTT topic and payload design of this “command & control channel” to make it fit with Kotori? The background on this is that a web-based user interface for sending these commands is planned so this “command & control channel” should also be accessible via HTTP.

Thanks again for going forward with this important topic!

Sure, always welcome. Will also be happy to help with generalization, packaging and uploading the code to PyPI if desired.

Cheers and have a good weekend!

It’s all up to you. It just depends on your Python skills. ;) I currently invoke the commands manually but you can of course let the service on your machine or on elbanco let execute actions at certain times in order to push data to your Telegram bot. btw, my Grafana alarms are set up to get pushed to the same bot channel.

As said, this my “command” solution is very much aligned to a LoRa-TTN-MQTT setup, while “data control” could be easily rebased to a hiveeyes MQTT subscription. LoRa Class A devices have a downlink window after each uplink being sent. Data goes directly from the bot to the TTN backend and then to the device. If LoRa receives a higher attention and usage among us, I can imagine Kotori to get extended by such interactions.

The Kotori documentation already provides guidance for sending events over MQTT. If this feature is working as intended, I (we) just need to implement it properly into the bot service.

1 Like

It took me a bit longer to make the service ready for publishing. It has undergone bigger changes since my initial working version.

Setting up a Telegam Bot instance: see here


  • Hiveeyes MQTT subscription is currently only possible to single topics
  • TTN MQTT subscription optional
  • requesting weight and battery voltage
  • configurable vocabulary for weights and battery voltage of the Hiveeyes universe
  • requesting Grafana graphics
  • log events into InfluxDB based Grafana annotations
  • send a daily summary (weight + daily delta) at sunset or custom time
  • rudimentary support for sending uplinks to a TTN device (depends on LoRa device firmware)


  • /weights print current weight and delta compared to last time the command was invoked.
    also prints date+time of latest data package
    old data is saved in a file to survive script restarts
  • the /weights command lists more commands for showing Grafana graphics which are configurable by subsections of the URL. Currently linked to my dashboard.
  • /enable_daily Without arguments: set a daily timer at sunset time for summary which prints current weight + daily delta + todays sunset time. Sunset is calculated from lon/lat position and weight from last summary is also stored in a local file.
    command accepts hour and minute for a custom time, e.g. /event 20 15
  • /batteries print current battery voltage when available
  • /event send event (title and text) via MQTT to Kotori which will appear in Grafana
    (Grafana Dashboard needs configuration to retrieve the events from an InfluxDB events series)
  • /sleep for my TTN setup to set a one-time sleep duration

I run this script as a systemd service which works pretty well.

As you will recognize, my Python skills are everything but perfect and I encourage everyone to improve the service and make it more efficient. New ideas and added functionality is very welcome as long as it not just serves very individual solutions. Let’s keep it as generic as possible.


  • For beekeepers observing multiple hives extend the output dynamically depending on the number of hives recognized through the MQTT subscription.
  • include graphic of weight development into daily summary



Appreciate it, thanks @thias!

As i am currently preparing for a conference, i am not able to go into the details, bummer. From what i can see, the feature list is really impressive and all of this looks very powerful and well-designed in general. Kudos!

I will be happy to integrate it into the system for all people not being able to run this bot on their own behalf and add appropriate multi-instance features. Or does it have multi-tenant capabilities already / is it able to dispatch notifications to multiple beekeepers?

Thanks again for your contribution!


Ah, it’s mentioned here already, thanks.

I don’t see it as a one-instance-cover-all solution. Instead running individual instances of the script adapted to user-specific needs makes more sense to me. Having it all in one bot instance would result in messages to/from one user getting pushed to everyone. From my point of view this could be a base for individual deployments with an invitation for further development with features that clearly enhance the usability and functionality for all, e.g. the data handling of all hives from a single beekeeper (ToDo #1).

Edit: Systemd service file added

1 Like

Thanks for shedding some light on this and keep up the spirit!

Dear @Thias,

just wanted to give you a heads up on this as @einsiedlerkrebs, @vinz and I are currently thinking about aspects and semantics of a (generic) C&C channel again while working on GitHub - hiveeyes/hiveeyes-micropython-firmware: Hiveeyes MicroPython Datalogger -- Data logging for humans.