Monitoring with Rasberry PI

[dopey]

Hello

I've followed a few of the pi projects on the internet, yet still want to try my own solution

Also want to focus on monitoring, trends, and alerts.. Don't quite feel comfortable controlling outlets..yet

General design/plan:
Rasberry PI gathers data from probes using python
Push to AWS Kinesis -> Firehose -> Elasticsearch
Graphs/dashboards via kibana/grafana
Alerts via python by querying elasticsearch

Then I can create graphs/dashboards of trends over time. At the moment have one for Temp going:


Got this going this evening, the tank doesn't have a heater yet -- hence the low temp

I am curious what other probes out there exist one can tie in to the pi, either usb, 3.5mm jack, or gpio board? Temp was an easy one.. i'd love to find:
Ph
Alk
Salinity
PAR
Ammonia


I got pretty excited about the seneye but I didn't see many had success accessing the probe direct in linux via usb, so haven't ordered one. Also refuse to run a windows machine nor buy their overpriced wifi hotspot for it.


(I haven't put my code up yet, can if people interested.. at the moment it's a couple python scripts running in a screen..first evening working with it)

 

[Ranjib]

Nice . Curious why elastic search?
Keep us posted.

 

[dopey]

The PI ran all night without issue, data is all present in AWS.

Some notes though:
AWS cost are too high Since starting Kinesis, Firehose, and Elastic service the AWS cost was $3 USD -- Way, way too high for such a small amount of data/project. It is primarily the 'elastic service' that cost money.

I've adjusted the cluster configuration, but may ultimately push to my own dedicated server hosting I already have.. Mainly did this to play with AWS... but i'm a bit oldschool and prefer my bare metal with things I install.

@Ranjib I work allot with ELK stack for work, and has always been a side passion of mine. Beyond that, I know how to work with ELK stack, and it's a simple efficient data store for the information long term. But yes may be a bit overkill, since at work we push around 50M entries an hour into elasticsearch... This is 1 per minute at the moment

I think pushing into elasticsearch let's one easily use grafana or kibana for visualizations instead of writing those into your website yourself.

I may end up going with kafka/mongodb type solution long term, or kafka/elasticsearch long term.

I think the main difference between your project(and maybe i'm completely wrong!), is instead of doing much of the work on the rasberry pi side, i'd like to do it in the 'cloud'(or rather a hosted server). Mainly leverage the pi to gather data locally, and push to the internet where it's stored/crunched/displayed.

 

[Ranjib]

Yes. reef-pi does everything on the Pi itself. I went with that route since I wanted reef-pi to be usable by other builders, and keeping things self contained radically simplified the installation/configuration process. It was also doable performance wise, because go is very efficient , and I am able to do all the stuff (around 30+ threads across 7 sub-system) with less than 30% cpu/memory footprint. It was an explicit design goal to make it modular (i.e one can run reef-pi just as a doser or light controller without anything else, including without internet or network at all)

I was curious about elastic search because you have to feed it text data and the index it, so generally its good for things like logs and other full text search. For your use case influx or prometheus like time series db would have done the job. But if you have prior experience with elastic search, then I can see the vantage point

Notably, there are third party services such as freeboard and adafruit which will let you submit data straight and you can build your dashboard there.

None the less, DIY controllers are awesome by their own rights , they joy and lessons you'll learn is invaluable. Looking forward to your build.

 

[dopey]

Very impressive project! Definitely one of the most thorough ones I found when doing some research, and one of few still active

Certainly agree both of those of worked well, also think mongodb be a good choice for storing since i'll mainly work with json when formatting data/storing it. Think I like the idea of showcasing grafana/elk as a solution if I were to write this up on my personal site.

Have you ever considered using the Seneye? When I look around for probes, I end up with the Atlas Scientific quite often, but the sheer cost of each probe quickly outcost that of Seneye.

I found a couple people who have read the usb stuff via linux, and looking today I see they do release their SUD driver, even citing raspberry pi as an example client.

It seems like it be the most cost affordable option to get Ph, PAR, Ammonia, etc ?

I am pretty close to ordering it..Well assuming I can find it in Sweden Their site direct adds around 60pounds for shipping

For me, i'm more focused on monitoring at the moment but if one could get the data out of seneye *then* control local outlets from it to shut off/on accessories.. I could see a very sleek pi+seneye controller setup.

 

[kapelan]

Would say Raspberry PI is not stable.
I have a project with Arduino and Raspberry.
Arduino is working as a controller Raspberry is working as web server and storage.
I.e. Arduino constantly send messages to Respberry with all available parameters, Rasberry keep save them to MySQL DB and provides web interface to display data.
Problem: once in a couple of month MicroSD just dye.
The point is MicroSD is not designed for intensive Read/Write operation. But MySQL constantly writing data to it.

 

[Ranjib]

Would say Raspberry PI is not stable.
I have a project with Arduino and Raspberry.
Arduino is working as a controller Raspberry is working as web server and storage.
I.e. Arduino constantly send messages to Respberry with all available parameters, Rasberry keep save them to MySQL DB and provides web interface to display data.
Problem: once in a couple of month MicroSD just dye.
The point is MicroSD is not designed for intensive Read/Write operation. But MySQL constantly writing data to it.

There is nothing wrong with Raspberry Pi, sd cards are always fragile component and its is upto application designers to use it judiciously. You should consider using a usb mounted hdd or some other reliable storage if you want to do heavy I/O operations. You can also consider architecting your application to minimize disk i/o (i.e. use in memory data structure and writes to disk only for things that need to be). MySQL is built for enterprise grade deployments that can scale thousands of iops and tera bytes of data. Consider using something much light weight and rearchitecting your application to use caching and other in memory reads.
We use boltdb (an embedded key value store), for reef-pi, which churns through lot more data than just ph. But we only serialize state on disk (i.e. save things on db) if a write operation happened (i,e, new things are added or existing things are removed). I have builds that are running over 4 months (I think there are atleast three other reefer with higher uptime than me).

If nothing, consider using an external hdd, that should fix the reliability issue, but you incur some extra cpu and power.

 

[dopey]

I haven't ordered any probes yet besides the temp ones, though it's definitely tempting. It looks like the atlas are the only ones people use, is it just not possible to get a neptune probe to work on a rasberry pi?

I've shifted focus now to recording the manual test measurements I do via google home/assistant.

The temp is done automatically every minute by the probe.
The rest are done via voice updates to google home when I take the manual measurement. "Hey google, record ammonia measurement of 0' is all I say. IFTTT then sends a webhook to my webserver which pushes the update, and it's graphed here with grafana.

I think it's practical. I had started using an android app, but found it a bit clunky to open and add each measurement. This is easier, and ultimately the main point is to have the historical data of measurements over time.

If I decide to get a probe of any kind the update mechanism will be the same as the temp probe. Otherwise I can compliment with voice for ones I do by hand.

Think this is more DIY monitor/tracking than controller, but so far quite pleased with it.

Next i'll write some alarms for the temp probe to e-mail me if they go out of range, as that's the main 'drop everything and ruunnnn home!' type alarm.

Will also get a couple float switches for the main tank and ATO container.. the other 'gotta get home asap' type moments.

 

[Ranjib]

I think you should be able to use the neptune probes with atlas ezo circuit, and then hook the whole thing with Pi

 

[dopey]

I ended up buying a Seneye a few weeeks back. I will try to write up an article on my personal site soon, but figured i'd share here. I've gotten this working!

Before purchasing I stumbled upon exactly one blog talking about doing it in python, and as well as the SUDDriver in C++ by Seneye themselves.

Unfortunately the python script shared on the site didn't work, ever. The values it reported back from the device was also flakey. The same C program from Seneye did work though, but it wasn't really usable in it's sample form. (Interactive gui).

I actually hacked together a C program to just print to stdout, but during that journey realized the problem with the python script I had found.

Anyway, here is my working python script. Just enabled the cron now, data is flowing in:
https://github.com/jpyth/seneye-python/blob/master/seneye-pi.py
It was heavily inspired by these two. I decided not to fork MQTT as i'm not doing MQ stuff, and it was basically a rewrite..
https://github.com/dhallgb/Seneye-MQTT
https://github.com/seneye/SUDDriver

I haven't put up the bad C program i put together, but can if anyone is interested.

The main problem is the python script just did two blind reads and parsed the result. After building up a C program from reading the sample application I realized that was the wrong approach. You basically have to send it a command(HELLOSUD), then try to read it until you get the expected bit/response back. Which gives some details of the device. Then send READING, and do the same. At that point you have good data to parse for PH, temp, etc.. And finally a BYESUD to leave the device.

Time will tell if it'll stay stable. I have an hourly cronjob set to read the Seneye Device and send the following towards a RESTAPI.
{"value": 24.375, "measurement": "Temp"}
{"status": false, "name": "InWater"}
{"status": true, "name": "SlideNotFitted"}
{"status": false, "name": "SlideExpired"}
{"value": 8.26, "measurement": "pH"}
{"value": 0.001, "measurement": "NH3"}
{"value": 24.625, "measurement": "Temp"}
{"status": false, "name": "InWater"}
{"status": true, "name": "SlideNotFitted"}
{"status": false, "name": "SlideExpired"}

As I write this, I can see the true/false section isn't accurate.. guess I need to look into that

Here's the current graphs.. yes I am behind on testing, life got busy and i'm playing catchup.


The current setup is following:
2x Temp probes -- Checked via shell script and pushed to webserver
IFTTT integration between Google Home and Rest API on my server
Seneye - Reading PH, Temp, Ammonia once an hour, pushing to Rest API on server.

The IFTTT integration is really slick. Works on my google home, and my phones. As soon as you finish a test, just say 'Hey google, Record Ammonia measurement of 0". Done, it grabs the underlined bits, and sends a bit of json towards my server.

I think next is to setup some email alarms for temp/ammonia.

 

[tuxypenguin]

Does it have to have a slide in it for the Python code to work?

Interrupt OUT isn't available.


pi@raspberrypi:~ $ sudo python test.py
DEVICE ID 24f7:2201 on Bus 001 Address 004 =================
bLength : 0x12 (18 bytes)
bDescriptorType : 0x1 Device
bcdUSB : 0x200 USB 2.0
bDeviceClass : 0x0 Specified at interface
bDeviceSubClass : 0x0
bDeviceProtocol : 0x0
bMaxPacketSize0 : 0x8 (8 bytes)
idVendor : 0x24f7
idProduct : 0x2201
bcdDevice : 0x100 Device 1.0
iManufacturer : 0x1 SENEYExUSBxv1
iProduct : 0x2 SENEYExUSBxv1p05
iSerialNumber : 0x3 <REDACTED>
bNumConfigurations : 0x1
CONFIGURATION 1: 100 mA ==================================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x2 Configuration
wTotalLength : 0x22 (34 bytes)
bNumInterfaces : 0x1
bConfigurationValue : 0x1
iConfiguration : 0x0
bmAttributes : 0x80 Bus Powered
bMaxPower : 0x32 (100 mA)
INTERFACE 0: Human Interface Device ====================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x4 Interface
bInterfaceNumber : 0x0
bAlternateSetting : 0x0
bNumEndpoints : 0x1
bInterfaceClass : 0x3 Human Interface Device
bInterfaceSubClass : 0x0
bInterfaceProtocol : 0x0
iInterface : 0x4 HID
ENDPOINT 0x81: Interrupt IN ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x81 IN
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x8 (8 bytes)
bInterval : 0x20

 

[borillion]

This is pretty cool, I was thinking of picking up a seneye and looking at graphana myself since we use it at work Good to see others had the same thought.

 

[borillion]

Also I just found this from seneye's github repo. https://github.com/seneye/SUDDriver

 

[dopey]

I am still using this

Pretty sure this is close to what im running, haven't touched the code in a few years now I think.
https://github.com/jpyth/seneye-python

Only issue i've had is the rasberrypi locking up. I haven't spent any time trying to figure this out, just assume it's the nature of these small devices. -- By that I mean i've never hooked a 'frozen' one up to a monitor to see what it is doing. It becomes completely non responsive from any commands remotely (ssh).

To cheat (I'm lazy) I added some simple logic to do a reboot if it fails to post the results and has been 'up' longer than an hour. That did help, but still every month or so I get a 'no data alarm 'from grafana and need to powercycle the rasberry pi..

Just a note; you cannot register a new slide in linux. You need to connect it to a windows PC (or VM) and register a new slide. I emailed seneye years ago and never got a response


If you do this yourself the general logic is sending the hello, polling for an expected response, sending a read, then polling for correct return bit, then parsing out the results.

The c program worked perfectly for me as well, but it's a CLI UI and requires input to get info. It was useful to understand the logic/intereaction but unusable to automate/save readings.