Enviro pHAT - Potential concurrency issue

Hi all

This is my first post, so be kind. Hopefully this will help someone, and maybe someone can come up with a better reasons for me getting the behaviour I did.

I recently purchased an Enviro pHAT (EPH) board, have built and have been running it gathering temperature and pressure readings in my office for a few days with now issues. Like many, my EPH is coupled with a Pi Zero W, I am running node-red on this and firing the readings off via mqtt towards another Pi (Model c) at home which is running mosquitto, InfluxDb and Graphana. In my setup I am using very small python scripts to return single values (i.e. Temperature) and processing everything else within node-red. Timing and triggering is via the node-red agent as well. As an example, here is my read-temperature.py

import time
from envirophat import weather
temp = weather.temperature()
print(’%f’ % (temp))

Anyway , , , , , up to this point two items were being collected on 10 second triggers - temp and pressure.

Last night I started playing around with the accelerator (Thoughts along the lines of - “Can I detect the kids looking for thier xmas presents with the accelerometer”) and so I added a 3rd flow with this movement script, combining all three axes into a single magnitude value. Triggering this on a 10 second interval as well.

import math
from envirophat import motion
x, y, z = motion.accelerometer()
mag = math.sqrt(xx + yy + z*z)
print(’%s’ % (mag))

From that point on, the values of my temperature and pressure flows become unreliable, in some cases recording the temperature in my office at 121deg. I noticed this this-morning and scratched my head over it for a while.

Checking mosquito and influx, all seems normal, values were being brokered and stored as rxed.

Before tearing my hair out and changing everything, I wondered if the 10 second timing interrupt was being sent to all flows essentially simultaneously and all three scripts were executing in separate contexts, but attempting to access the same hardware (occasionally concurrently) leading to the unreliable results. To investigate this, I implemented (In node-red) a 2 second delay line between the trigger of each flow. Since I put this in place the sensor readings have stabilised markedly. This can be seen clearly in the below sample curve with me introducing the accelerometer script at around 10pm, a lot of inconsistent readings into around 1430 today when i introduced the delay chain. similar graphs exist for pressure. I have not looked at accelerometer data yet

image

It sounds like your problem, your rationale, and your solution are all sensible.

Indeed, there may be concurrency issues with accessing the hardware on Enviro pHAT since all communication is accomplished via the single i2c bus.

It’s curious that there’s no locking, or otherwise, implemented at the OS level to prevent different i2c transactions being intermingled. I suspect the reason for this is that it’s easier to let the user shoot themselves in the foot and explain why they shouldn’t, than to implement features that might cause an unexpected deadlock, delay or overhead.

Your approach seems sensible. I’ve precious little experience with Node RED, but all of our Node RED nodes implement a similar pattern: https://github.com/pimoroni/node-red-nodes

They include a Node JS wrapper which launches a Python script, and communicates to it via STDIN/STDOUT. This pattern allows continuous communication between Node/Python and would allow you to, for example, stream all of your sensor data in 1sec intervals and then filter it accordingly in Node RED.