the most shocking part is i might have a usecase for this

the active energy field is pretty sussy but it's just a 4-byte integer sucked off as 2 2-byte ones, $ printf '%4s\n' $(printf '%s\n' obase=16 58932 60 | bc) | tr ' ' 0 | tac | paste -sd\\0 | bc
399634 and that's what the LCD shows too

sysv message queues? kinda slick with it; world's most insane interface, natch, but

also thanks to @ThePhD's n3030 i can have enum or_we_504_msgtype : long { in c and c++ with -std=c2x, which makes this much less insane

and yes the raw format is 3c 00 0f f5 for 3`994`895 (0x003cf50f), so two LSB u16s pasted together MSBly, which is PDP-11 middle-endian. plus ça change

falling edge trigger feasible if i manage to talk to the GPIO

also lol the integration time on this meter really fucks it, mathematically it comes out to 1mA, i measured 848μA with a jumper

which, idk. sux.

as elucidated by the (entirety of!) OR-WE-504_MODBUS_Registers_list.pdf ive finally managed to dig up. lets see!!!!!

register 6 is what the manual says, register 15 is what it returns the address when reading. save me from this hell

in that you need to broadcast the address change, not just send it, and they explicitly say to send it to the device

hey, guess what doesn't work in modern mbpoll, that i remember glancing through when initially trying to connect…

Some RTU devices need to get initialized to a certain address via the 0x00 broadcast address. But currently RTU_SLAVEADDR_MIN is defined as 1

lol. lmfao.

and i cant "emulate" the meter well enough by just reading from the USB/serial adapter

so i snapshotted the entire pool on my laptop and installed wine32 and mono and ms fonts and deleted my wine config because it wouldnt load

i cannot get it to work regardless of the arcana i do and how i torture it, despite posting the same data as the configger; i think its because of modbus's explicit precise inter-byte (inter-message? both?) sleeps that libmodbus boasts about not having

itll be in Attic/ for posterity but for my usecase i can just set the addresses and serials once manually :v

clown shit

(the -L. is for libmodbus, im not installing armel-native packages just for this)

i also dont think i posted the shart link, if you also have some polish leccy meters (though I suspect the impulse driver will be relatively universal):

maybe the SD card wont explode instantly after all

gpio.h my beloved

such a nice api

brain geniuses on Elektroda

as in: you just say what you want in GPIO_V2_GET_LINE_IOCTL, that gives you an fd to read, you sleep in read, and it's pre-timestamped. i cannot get over the usability of this

and theres drip mode as well:

(idk how well this comes out, the blinks are short and i have no explicit control over the frame integration time)

i gamed down the golden image rootfs to 324M used too, which is ~acceptable when keeping all modules and firmware i think

with 1/min polling of ORNO-MIB::orno, as is the expected real-world condition

/usr/local/lib/udev/rules.d/99-ORNO.rules with SUBSYSTEM=="gpio", TAG+="systemd" does its magic, though, admittedly, this is largely frivolous on a coldplugged device

and i need a resistor Somewhere to trigger the usb host, too bad the raspberry pi is entirely undocumented so i dont have a fucking clue where, if at all, the Special Pin is available

and I/O works, even! well, just O, i guess, havent gotten a response from the meter

and the only thread in which they're mentioned is [HELP] Raspberry Pi Zero W V1.1 - Test Pads problem; those three mean that there just don't appear to be zero w test pads listed at all, anywhere

and the foundation provides dtoverlay=dwc2 to set the controller to default to device

they changed it in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bcc76c4014dce4e3834dbd5b7f6593cbcfbfebe0, which, y'know, fair enough, i can just build a dtb w/o otg, but still very annoying to me, personally

where "intermittent" means it just worked for 16h straight, but then it didnt after i rebooted for new device tree and jiggled it around, but then it worked once, and im guessing this shit would

too bad i noticed after i cut off the wires in preparation to solder them to the second, working adapter. turned a 20 second job into a 7-minute one, and instead of the incredible strain relief system™ it will now be a squeeze of cum

[time readout column is in ns]

is this because i used a device tree from 6.2-rc1 instead of a matching 5.10 one :v

$ dtdiff ~/uwu/p16/boot/firmware/bcm2835-rpi-zero-w.dtb{.orig,}
--- /dev/fd/63  2023-02-26 21:57:08.472157491 +0100
+++ /dev/fd/62  2023-02-26 21:57:08.472157491 +0100
@@ -681,10 +681,7 @@
                        clock-names = "otg";
                        clocks = <0x16>;
                        compatible = "brcm,bcm2835-usb";
-                       dr_mode = "otg";
-                       g-np-tx-fifo-size = <0x20>;
-                       g-rx-fifo-size = <0x100>;
-                       g-tx-fifo-size = <0x100 0x100 0x200 0x200 0x200 0x300 0x300>;
+                       dr_mode = "host";
                        interrupts = <0x01 0x09>;
                        phy-names = "usb2-phy";
                        phys = <0x17>;

oddly, i saw the led on the meter blinking on the preview on my phone but not in the video. oh well

but prometheus-snmp-exporter appears fundamentally broken, so

wish they could all be like this