Monitoring on Pi Zero W with multiple RuuviTags


#21

Perhaps a MS Windows thing. I’ll try that here and post results.

Notice your screen shot stating that the image is 2.21GB (wrong)
Notice your screen shot \.\PhysicalDrive2:UNKNOWN: unknown error, write .
What brand SD card are you using?

Maybe etcher for MS windows does not like 32GB image?

I tried version 1.5.19 and it said image was 866.89 - wrong
As expected after flashing for a minute or so it said 99% complete although it did keep on writing! And eventually completed.


#22

Thanks again for testing! It doesn’t matter though, it’s all up and running now.

I am using a SanDisk 32GB card. I used Win32DiskImager for my own backup and wrote back the image after formatting to verify it worked too.

Etcher I’ve never used before.


#23

I have the image from dgerman running on a Rpi zero w with one tag.
Just checking/testing to see if the battery/solar system I have can support the load.
Next thing is to see if the data from six tags can be displayed and still readable.
Does anyone have a multiple tag system running and how did you get the data from all the tags displayed in such a way that its still clear?
Heres my rudimentary test system display with a single tag.


#24

You could check the live demo at lab.ruuvi.com for an example on how to organize data from multiple tags.


#25

Thanks Otso, yep I see that now and it may well be what I want.
I have the image safely loaded onto an sd card and get the Rpi GUI after booting up and apparently both BLE and Wifi connections are up, but what then?
Do I need to start influx, grafana and ruvvicollector separately, and if so, how?


#26

They are started by systemctl, refer to the directory:

/lib/systemd/system

influxdb.service, chronograf.service, grafana.service and ruuvicollector.service

See also related links in /etc/systemd/system/multi-user.target.wants
influxd.service, grafana.service
and
ruuvicollector.service.requires


#27

Regarding "see if the data from six tags " does something like

SELECT “temperature” FROM “ruuvi”.“autogen”.“ruuvi_measurements” WHERE time > :dashboardTime: AND (“mac”=‘D3517872EC0F’ OR “mac”=‘F7FA744A1E1A’ OR “mac”=‘E9383FDD20BC’) GROUP BY “Mac”

Do what you want?
See http://dalogger.dyndns.org:3430 and check out dashboard 3sensors


#28

Is the image still available at https://mybeacons.info/raspiruuvixxxx.gz?


#29

Actually http://MyBeacons.info/RaspRuuvixxxx.gz


#31

Thanks dgerman


#32

Hi @dgerman,

Thanks for your active involvement RE Ruuvi gateways and collecting its data :slight_smile:

I’m running through some threads here and saw that you might have an image for the Pi Zero W. I’m aiming to run RuuviCollector on the Pi and then publish payload via https to my own cloud setup and NOT InfluxDB and Grafana setup.

  1. Can I ask, is the image the same for Pi Zero W and Pi 3B+?
  2. How should I be altering the RuuviCollector to publish the payload via a https request?

Appreciate the help!

Rgds,
Wzz


#33

The SD image at MyBeacons/RaspRuuvixxxx.gz is for Pi Zero W.
Most importantly because of grafana, SO you might not care.

  • Pi Zero has a different processor: BCM2835 ARM11 using an ARMv6 <- Important

  • Pi 3 Broadcom BCM2837 CPU: 4× ARM Cortex-A53, 1.2GHz

  • Pi 3 Model B+ 1.4GHz 64-bit quad-core Broadcom Arm Cortex A53

I will try it on … later today


#34

You don’t necessarily need to alter RuuviCollector, if you are able to parse InfluxDB line protocol on the receiving side, as the connection between RuuviCollector and InfluxDB (in the standard setup) is standard HTTP POST. In this case all you need to do is to change the influxUrl configuration property.

For example, if I changed the influxUrl to http://example.com:1337 then RuuviCollector would do a HTTP POST to:

http://example.com:1337/write?db=ruuvi&rp=autogen&precision=n&consistency=one

or with influxUrl of https://example.com/some/path/ it would post to:

https://example.com/some/path/write?db=ruuvi&rp=autogen&precision=n&consistency=one

(parameters depending on exact configurations) with following kind of data:

ruuvi_measurements,dataFormat=5,mac=D7D09A60357B absoluteHumidity=4.0374809476748155,accelerationAngleFromX=73.86213543428374,accelerationAngleFromY=16.145033821861915,accelerationAngleFromZ=89.53160256963027,accelerationTotal=0.9785949110842544,accelerationX=0.272,accelerationY=0.94,accelerationZ=0.008,airDensity=1.2148683985819957,batteryVoltage=2.983,dewPoint=-1.415840196649157,equilibriumVaporPressure=2764.5917289802787,humidity=19.9375,measurementSequenceNumber=4055i,movementCounter=117i,pressure=103319.0,rssi=-63i,temperature=22.74,txPower=4i

(note that with batch mode there can be multiple lines like the above (from different tags) in the post data if the measurements are received within the configured influxBatchMaxTime (default 0.1 seconds) of each other)

If you need more fine-grained adjustments, you need to create your own implementation of a DBConnection, you can take a look at the InfluxDBConnection.java and DummyDBConnection.java for examples. You also need to add it to the config.


#35

So you aim to use the limited processing power of the Rpi to handle Ruuvicollector and do the hard work at the receiving end?
Sounds sensible. :slight_smile:


#36

Hey there @dgerman,

Really thanks. I’m not too interested in grafana at this stage -> haven’t really worked with it before - probably need to look into it since everyone else is working with it :slight_smile:

Rgds,
Wzz


#37

Hi @Scrin, thanks for the pointers!

I’ll revert on this for others that might have the same line of thinking. *although, I won’t call myself a HW dev at all, but can dig quite well and love to break things until they work :rofl:

Rgds,
Wzz


#38

Hey @Motobiman.

Yeah, that was my initial idea - thanks for affirming! I haven’t checked which modules are available on the Ruuvi to allow some simple edge processing instead of harvesting all the data straight into a db though… collecting is good up to the point your bank account breaks because of all the cloud space you occupy…

What are your thoughts on the collection process? @dgerman @Scrin, you’re welcome to jump in here if you’d like…

Rgds,
Wzz


#39

For my application, beehives, I need to be made aware of change rather than being able to look at days and weeks of unchanging data.

I would be happy if the whole system, how ever it is configured, worked in the background and was only powered up for a few minutes every quarter hour and ignored all temp, humidity, battery voltage and movement data within pre-defined limits but raised a red flag for that tag when its data went outside those limits.

The comms has to be over cellular networking as the collector site is remote without Wifi or mains power.

Frankly this idea of watching unchanging data, from sensors a few yards away from me, however pretty the page, leaves me cold, as for example if you miss a serious temp drop or movement in a hive, by the time you do notice it, the damage is done and often unrecoverable.

Data change and an effective warning of it, say by a text message to my phone, is what I need.

Sent from my iPad

PS
Having a camera on the Rpi and being able to view the image over cellular network might save me a drive to the apiary site too.


#40

Regarding Alternate processing: Scrin’s description at 4/16/19 03:27 above and his excellent idea of providing the ability to provide the influxURL, makes routing to another web page process very easy.
I have had some ideas regarding the use of syslog to route the data see http://mybeacons.info/jakoavain.html

Regarding monitoring changes. I have noticed that grafana has alerts. As this is the best program I have seen in over 30 years, at least for processing data, It seems they have thought of that too, but I haven’t investigated how to use that.

Regarding remote site: Motobiman and his bees have got me so interested that I am pursuing using using http://www.uugear.com/product/wittypi2/ as per https://f.ruuvi.com/t/is-the-swamp-too-deep/3401


#41

Hey @Motobiman.

I get it. I have the same kind of objective here with comms and notification. So, I like your thoughts.

With some of my other controllers that are running Node, I would pull the limits you’re talking about from my api to the device and then edit the broadcast loop to adhere to those limits - i.e. only broadcast when sensor data is in error. Hence,

broadcast loop every 1000ms => if temp >=< desired temp then do http request. The algo can be much complex than this, taking into account a sequential rise in temp…

This is all good in on some of the other stuff I managed to accomplish, but Ruuvi habitat is a bit new and still need to find my feet here…

As soon as I have my setup up and running I’ll send through some thoughts on how I approached it!

Rgds,
Wzz