Hack Session

[beadon]

Hey @David00 ! I'd love to spend some time working wth you on the CI/CD pipelines for this repo. Do you have time on Saturday Feb 11th 2023 ? I think we could knock out some big pieces and even open it up to a broader group.

If something like this works well, then broadening out to other developers or user communities could be neat way to MVP a bunch of new features people have been itching to try, but haven't had the push to contribute.

Phsae 1 , a go ?

[David00]

Hi Bryant, yes, I do! I am aware of CI/CD's capabilities from a high level, but I haven't done too much with it.

I know it will be needed for this project to scale, and I appreciate you pressing forward with this discussion and also #68.

I do have a busy rest of the month, but I'd love to take advantage of your motivation and begin the discussions now to plan for the future!

I'm in the Pacific time zone, and I'm thinking carving out an hour or so between 10AM and 2PM (PST) would be ideal for me.

I also like the idea of opening this up to a broader audience, and this might also be a good opportunity to start building a community environment, perhaps a Discord server.

[beadon]

Sure, let's rock. How about 2PM ET / 11AM PST tomorrow ?

[David00]

Works for me!

[beadon]

Good stuff, phase 1 was a success !

We discussed:

1. CI/CD and the generalities of what it's good for -- usually "get code from one place and do all of the checklist items to deploy to production". This includes testing, qa and packaging.
2. We got GitHub actions up and working based on a commit ! ( detail on the v0.3.0-workflow-testing branch )
3. You were able to write a fast test to prove that a failing /passing test populated to the Git Actions (pytest)
4. We discused the value of versioning, and SemVer (semver.org)
5. Discussion on GitFlow and value of this tool as the size of the team grows.
6. Discussion about deprecation of the SD Card image, in favor of a fully packaged solution using APT , which will solve the deployment, documentation and support headaches that prevent wider adoption today, and otherwise are a time sink.
7. Discussion about using a DMA instead of the Pi CPU to manage the timing loops for SPI polling. Brief discussion on microcontrollers.
8. Discussion about the use of Grafana, and the need for simple out-of-the-box dashboards that just work, will go a long way.

[beadon]

For web interfaces - consider the use of LuCI. https://github.com/openwrt/luci/wiki/

The bonus for this is that this can offer you extensibility to make this power monitor an "add on" to any wireless router. There are a number of commercial routers that can support this type of integration, either over USB, or some kind of wireless, or many times opeing the router to expose JTAG or serial interfaces.

Honestly, if you build a coin-cell (or AC power harvesting) based A/C measuring device that relays the data using something like Bluetooth .. this can all be ralyed to a router-like device, or a simple usb-connected addon... these don;t appear to exist yet, but there have been some advancements in 2022 on the subject (reference below).

Reference design for power harvester : https://users.ece.cmu.edu/~vikramg/docs/hotemnets11.pdf
Further reading: https://upcommons.upc.edu/bitstream/handle/2117/375085/applsci-12-10699.pdf?sequence=1

However, this means that the circuit design, and polling will need to be heavily optimized to fit within the power budget.

[beadon]

One more cheater method to use AC for data communications. This wikipedia article covers this method in a lot of detail. https://en.wikipedia.org/wiki/Power-line_communication

Also, since we're measuring the AC at high sampling raters we also have the ability to see the "ripple control" which appears to be used by many power sttions to do clock synchronization and pass system control messages using the AC powerlines (!!).

I, for one, would be very intereted to see the messages crossing the AC powerlines to/from my house. Since this signalling is basically "broadcast" and tones, then the sampling frequency is very doable - we have to do Nyquist on typical frequencies are from 100[Hz]to 2400Hz -- meaning we have to reliably sample at 200Hz, to 4800Hz -- then using FFT and bandpass filtering, jam it in to a waveform for audio out.

[beadon]

Also, there wasa brief talk on microcontrollers -- after further research it looks like the STM32 is probably the cheapest, simplest option.

[David00]

Thanks for the summary, @beadon! This was very helpful and I'm looking forward to getting started on expanding the CI/CD with more tests, and I'll also look into setting up an apt package and repository.

Your other comments about signals embedded into the AC lines and the coin cell monitoring are super interesting, too. I've been waiting for a real reason to bust out FFT and higher harmonics analysis!

As we discussed, my schedule should begin to clear up next month, so we can expect to explore these other subjects in more depth at/after that time..

[beadon]

Next, for reference there is a neat little script that attached to an apt repo for debian-based installed over at the balena etcher project. This looks like a great starting point to repurpose the work to create a slick little apt repo for us here !

https://github.com/balena-io/etcher#debian-and-ubuntu-based-package-repository-gnulinux-x86x64