Why not actually running CI on your computer? Most CI system work via an agent, so you can join your laptop as a worker to the CI system?

https://docs.github.com/en/actions/hosting-your-own-runners/...

You could "favor" your own laptop as a target runner for the CI when it's your PR for example

https://docs.github.com/en/actions/writing-workflows/choosin...

If only because there are 100-1000x more system that have now tied themselves ne their data to said cloud

As a feedback, having all the examples in that gif on the readme centered around node almost made me look away without a second thought.

Why is standard etag support making the frontpage?

The Codescene product provides an in-depth analysis of knowledge distribution over time:

https://codescene.io/docs/guides/social/knowledge-distributi...

I recall seeing the linux kernel repo analysis as a show case, but I can't find it anymore.

Very cool, super useful from a jumpbox accessed via ssh for example.

Looks similar to azbrowse for azure: https://github.com/lawrencegripper/azbrowse

Bicep has the potential to provide a cross platform solution, but it’s unclear whether that’s the direction: https://github.com/radius-project/bicep-types-aws

I would not expect that to happen any time soon. Maybe they will see a chance to promote bicep more by such move. Yet until now they actively (and reasonably) advise in their docs Terraform use, if you consider multicloud and few other situations.

I would rather expect MS to declare support for OpenTofu. They don't even have to be involved in it directly.

The main work is ensuring azure providers compatibility (which is formally maintained by hashi). Add compatibility with Tofu to Azure Verified Modules [0] (a great project btw), and we have a clean way out of this by providing real help where it's most needed.

[0] https://azure.github.io/Azure-Verified-Modules/

On the fly speech translation but in the voice of the speaker

Or a different voice if the voice of the speaker or the way they talk is annoying

I wish that this was just a sdk built on top of a provider/standard. Amqp 1.0 is a standard protocol. You can build all this without being tied to a product or to rabbitMQ, with a storage provider and a amqp protocol layer.

I was very disappointed when I realized that the data showing from the app was 20min behind, and going through the cloud, while the Envoy box is connected to my local network and has a per-second stream.

their documentation is close to inexistant too. There were a couple opensource projects, with some snippets of code to get inspiration from to connect and scrape the data directly from the local API.

I did this and pushed data to grafana, but never took the time to share it.

Since my last attempt, it seems that more projects showed up that did a better job than me making it reusable :)

- https://github.com/petercable/solar-observatory

- https://github.com/vk2him/Enphase-Envoy-mqtt-json

- https://github.com/Matthew1471/Enphase-API

Thanks so much for your note and these links! Can't wait to give it a shake.

Thanks for the shoutout to my wrapper and docs too :)

My GitHub repo serves 2 purposes:

1. To provide a reusable wrapper (currently only Python, https://github.com/Matthew1471/Enphase-API/blob/main/Documen...) to talk to the LAN API, it's even installable via pip.

2. To document what the LAN API returns and all the URL endpoints (https://github.com/Matthew1471/Enphase-API/tree/main/Documen...).

I would like to see more people using the wrapper so we have a common way of talking to the IQ Gateway (there's a lot of tightly coupled projects on GitHub), but most people seem more interested in the docs I provide and rolling their own wrapper.

I always have plans to add more to it - I found multiple security vulnerabilities in the IQ Gateway and that allowed me to get a dump of the firmware - so there's plenty more URLs for me to write about :)

Thanks so much for your work and sharing. I'm excited.

Great that you're able to update settings... not just read data. I assume that changes to settings are synced with Enphase's cloud as if done with the cloud-based API.

I assume it's not possible or advisable to disconnect from Enphase's cloud altogether (please let me know if that's actually no big deal). [EDIT: Thanks for addressing this in your other comment.]

Enphase released a better EV charger* a few months ago, that's integrated with the other IQ stuff. It can dynamically send excess solar production into the EV instead of exporting to the grid (and can be set to top off the EV battery with grid imports in the middle of the night). I'll finish installing mine this week. ...Please consider incorporating that into your wrapper :)

I too am pretty quick to roll my own stuff. But I'll try to practice restraint, and leverage your wrapper (and treat it as a standard).

* https://enphase.com/store/ev-chargers/connected-ev-chargers-...