Uncategorized

GivEnergy and Polybar: Show stats from Solar array in my status bar

This was a quick fun hack to pull back the data from my solar inverter and display it in my status bar.

Here’s the code

view raw Readme.md hosted with ❤ by GitHub
#!/usr/bin/env python3
import datetime
from givenergy_modbus.client import GivEnergyClient
from givenergy_modbus.model.plant import Plant
try:
client = GivEnergyClient(host="10.0.1.254")
p = Plant(number_batteries=1)
client.refresh_plant(p, full_refresh=True)
def format_color(color: str, text: str):
return "%{F" + color + "}" + text + "%{F-}"
def format_wattage(input: int):
if input > 1000:
return f"{input/1000}Kw"
return f"{input}w"
def format_icon(input: str):
return format_color("#F0C674", f" {input} ")
surplus = p.inverter.p_load_demand < (p.inverter.p_pv1 + p.inverter.p_pv2)
if surplus:
lightening_color = "#2d862d"
else:
lightening_color = "#b30000"
output = format_color(lightening_color, "")
output += format_icon("") + format_wattage(p.inverter.p_load_demand)
output += format_icon("󰶛") + format_wattage(p.inverter.p_pv1 + p.inverter.p_pv2)
output += format_icon("") + str(p.inverter.battery_percent) + "%"
output += format_icon("") + format_wattage(p.inverter.p_grid_out)
print(output)
except Exception as e:
print("Error talking to inverter")
view raw givenergy.py hosted with ❤ by GitHub
[module/givenergy]
type = custom/script
exec = $HOME/.config/polybar/givenergy.py
interval = 60
Standard
Coding

Ryzen Ubuntu Server: Throttle CPU Frequency for power saving

This is a super quick one, I have a Ryzen server running a bunch of VMs. I noticed it’s running quite hot and pulling a fair bit of power.

As none of the VMs running are particularly performance sensitive I wanted to force the CPU to use a more conservative power setting.

First up, how do I see what frequencies the CPU is currently running at? For that we’ll use cpufreq-info, this will tell us what frequency each core is at:

cpufreq-info | grep current
  current policy: frequency should be within 2.20 GHz and 3.60 GHz.
  current CPU frequency is 4.23 GHz.
  current policy: frequency should be within 2.20 GHz and 3.60 GHz.
  current CPU frequency is 2.70 GHz.
.... more

Now how do I see what power draw this is causing, well that’s more complicated. In my case I have an APC UPS connected to the system to keep it up during power outages. This has a tool called apcaccess which gives me information about the UPS’s load. Knowing the size of the UPS you can back track from the load % to a rough watt’s usage.

In our case what I want to do though is use this to prove that changing the CPU has worked. Before making any changes it outputs 19% load.

apcaccess | grep LOADLOADPCT  : 19.0 Percent

To throttle the CPU we can use a govenor lets see what governors we have available

cpufreq-info | grep governors
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil

Cool, well powersave looks like a good one to try out, lets give that a go by running sudo cpupower frequency-set --governor powersave and then looking at the load and frequencies again.

lawrencegripper@libvirt:~$ sudo cpupower frequency-set --governor powersave
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
....
Setting cpu: 15
lawrencegripper@libvirt:~$ cpufreq-info | grep current
  current policy: frequency should be within 2.20 GHz and 2.20 GHz.
  current CPU frequency is 2.20 GHz.
  current policy: frequency should be within 2.20 GHz and 3.60 GHz.
  current CPU frequency is 2.20 GHz.
  current policy: frequency should be within 2.20 GHz and 3.60 GHz.
  current CPU frequency is 2.20 GHz.
....
lawrencegripper@libvirt:~$ apcaccess | grep LOAD
LOADPCT  : 15.0 Percent

That did the trick, apcaccess is reporting a drop to 15% load and CPU frequency is down to 2.2GHz.

I’ve got a smart meter for my home and can also see the drop in usage roughly reflected there too.

[Edit:] I also found this isn’t persisted between reboots. The following shows how to persist the change https://askubuntu.com/questions/410860/how-to-permanently-set-cpu-power-management-to-the-powersave-governor

Done. Server is now being more eco-friendly.

Standard
Coding

Ruby + Sorbet: Autogen sig method annotations

I’ve been adding Sorbet and type checking gradually to a legacy Ruby codebase dating back to the 2010‘s.

First up was getting all or most files as (a topic for another day):

# typed: true

Now I’m gradually adding method annotations, using sig annotations, to tell Sorbet what types a method accepts and returns, like so:

sig {params(x: SomeType, y: SomeOtherType).returns(MyReturnType)} def foo(x, y); ...; end

Docs: https://sorbet.org/docs/sigs

This is fairly time consuming so being lazy I wanted some help to get this done quicker.

I say “help” here as it’s never going to be perfect, with the meta programming and cruft of an old Ruby codebase it’s always going to need human validation and tweaking.

Luckily the codebase has a pretty extensive test suite so we can use that to validate the generated types match reality.

Let’s get Autogenerating

I’m lucky to work with great engineers, George (https://hachyderm.io/@georgebrock) is one of them. He showed me a useful approach to generate sigs which saves a bunch of time.

As sorbet “knows” some return types already it can infer some sigs on methods. The trick George showed me was to get it to add those inferred sigs for you automagically.

  • Set #typed: strict on the file, this means any methods without sigs are considered errors
  • Run srb tc --autocorrect --isolate-error-code=7017 this will tell sorbet to auto create any signatures it can work out
  • Reset #typed: true (unless you’ve solved all errors under strict – I’m aiming for that but gradually, currently want good sigs)
  • Review the auto generated sigs and make sure they’re sensible, fixing up ‘untyped’ and other issues

The cool thing here is the more sigs you have the better sorbet gets at generating the missing ones.

So what about those that can’t be created with this technique?

Well you have to write them but here there is help too. I’ve being using GitHub Copilot (https://github.com/features/copilot/) to infer or suggest sigs.

This is much more hit and miss than the first technique, it still (mostly) is a time saver but you do have to tweak the suggestions regularly.

Playing it safe with new sigs

Now I’ve got a set of new sigs you’d think next up would be to ship them but hold fire.

Sig annotations are statically checked at dev time but also, by default, enforced at runtime too.

The danger here is the new shiny sigs you added aren’t right and your production application will start failing when they are shipped.

To work around this we need to tweak some configuration in Sorbet. In this case I configured the app to raise runtime errors when a signature wasn’t correct but only in test or in staging environment – not in production. To do this you implement a:

call_validation_error_handler

This allows you to control how sorbet reacts to a method receiving or returning a type which doesn’t match the sig annotation.

Here is the initializer I ended up with:

# typed: strict

require "sorbet-runtime"

# Register call_validation_error_handler callback.
# This runs every time a method with a sig fails to type check at runtime.
# See: https://sorbet.org/docs/runtime#on_failure-changing-what-happens-on-runtime-errors

# In all environments report a sig violation to Sentry.
# In any non-production environment raise an error if a sig is violated.
T::Configuration.call_validation_error_handler = lambda do |signature, opts|
failure_message = opts[:pretty_message]
Scrolls.log(at: :sorbet_runtime_sig_checking, msg: failure_message.squish)
error = TypeError.new(failure_message)
track_error_in_sentry!(error)
raise error unless Rails.env.production?
end

Docs: https://sorbet.org/docs/runtime#on_failure-changing-what-happens-on-runtime-errors

There you go, ship the new code with its sigs and keep an eye on Sentry to see if any need tweaking based on real production usage without those causing production errors.

Standard