Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refresh project with Pi4 testrun #2

Merged
merged 12 commits into from Aug 14, 2020
Merged

Refresh project with Pi4 testrun #2

merged 12 commits into from Aug 14, 2020

Conversation

andrewnhem
Copy link
Contributor

Refresh project with Pi4 testrun

Confirming that it works with Pi4, though more tests with specific kinds of plants (with specific moisture needs) required for more confidence.

Also updated how it pulls in InfluxDB and Grafana to avoid builder errors.

Change-type: patch
Signed-off-by: Andrew Nhem andrewn@balena.io

@andrewnhem andrewnhem requested a review from chrisys July 25, 2020 00:18
@andrewnhem
Copy link
Contributor Author

I know I could just merge it myself, but I'm asking for a review bc of having solid principles/consistency, @chrisys .

@@ -20,7 +21,7 @@
print("Status code:"+plantsaver.status)

# Check if water level is too dry and that the pump wasn't on for the past 15 minutes
if plantsaver.status_code == 1 and pump_count >= plantsaver.pump_delay * 6:
if plantsaver.status_code == 1 and pump_count >= 6:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intentional? Looks like removing the delay would set it to pumping every minute if the tick is 10 seconds, but even so would be better to keep the delay variable and tune that downwards rather than hard coding?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oohhh... I read that all wrong haha. I thought that I could force it to pump every 6 counts until it hit some kind of target moisture reading.

I think my approach is wrong. I'll take another look.

Copy link
Member

@chrisys chrisys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for now; in the future this would be a good use case for testing the ability to provision dashboards using the new dashboard block. This one is heavily customised so there's no way we would be able to automatically get it right, so we need to be able to feed the custom built one into that block.

Copy link
Contributor

@phil-d-wilson phil-d-wilson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@phil-d-wilson
Copy link
Contributor

Also a candidate for the transport connector block.

@phil-d-wilson
Copy link
Contributor

Adding connector would be done the same way as I did the InternetSpeedTester. Change your code writing the measurements to create a JSON string, and ping it into MQTT:
https://github.com/balena-io-playground/internetspeedtest/blob/master/speedtest/speedtest.py#L35

Then your compose file can bring in influx, connector, MQTT, and dashboard:
https://github.com/balena-io-playground/internetspeedtest/blob/master/docker-compose.yml

@andrewnhem andrewnhem merged commit 50fa53d into master Aug 14, 2020
@andrewnhem andrewnhem deleted the pi4-testrun branch August 14, 2020 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants