Dazed and confused, but trying to continue 🇵🇱/🏴󠁧󠁢󠁥󠁮󠁧󠁿/🇷🇺 ⚧ they

Maintains homie/hoe stasis. Store horizontally when not in use. Contains sulfites.


   #!/bin/sh    base=.1.3.6.1.4.1.8072.9999.9999.1    get() {        case "${get#$base}" in            .0)                echo $get                echo STRING                echo hello world                ;;           .1)               echo $get               echo INTEGER               echo 8675309               ;;           *)               echo NONE               ;;       esac   }   while :; do       read -r op       case "$op" in           get)               read -r get               echo "get $get (${get#$base})" | logger               get               ;;           getnext)               read -r get               echo "getnext $get (${get#$base})" | logger               case "${get#$base}" in                   .0)                       get=$base.1                       get                       ;;                   .1)                       echo NONE                       ;;                   *)                       get=$base.0                       get                       ;;               esac               ;;           set)               read -r val               echo "set $val" | logger               echo not-writable               ;;           PING)               echo PONG               ;;           *)               echo "HUH $op" | logger               ;;       esac   done  $ snmpwalk  -v1 -c public localhost .1.3.6.1.4.1.8072.9999.9999 NET-SNMP-MIB::netSnmpPlaypen.1.0 = STRING: "hello world" NET-SNMP-MIB::netSnmpPlaypen.1.1 = INTEGER: 8675309 Feb 08 02:50:04 tarta Debian-snmp[2678083]: getnext .1.3.6.1.4.1.8072.9999.9999.1 () Feb 08 02:50:04 tarta Debian-snmp[2678085]: getnext .1.3.6.1.4.1.8072.9999.9999.1.0 (.0) Feb 08 02:50:04 tarta Debian-snmp[2678087]: getnext .1.3.6.1.4.1.8072.9999.9999.1.1 (.1)

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


SNMPv2-MIB::snmpSilentDrops.0 = Counter32: 0 SNMPv2-MIB::snmpProxyDrops.0 = Counter32: 0 HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (124201485) 14 days, 9:00:14.85 HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2023-2-9,16:17:23.0,+1:0 HOST-RESOURCES-MIB::hrSystemInitialLoadDevice.0 = INTEGER: 393216 HOST-RESOURCES-MIB::hrSystemInitialLoadParameters.0 = STRING: "BOOT_IMAGE=/@/vmlinuz-5.10.0-20-amd64 ro root=zfs:AUTO mce=dont_log_ce intel_iommu=on zfs.zfs_arc_max=96636764160 zfs.zfs_arc_lo" HOST-RESOURCES-MIB::hrSystemNumUsers.0 = Gauge32: 3 HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 0 HOST-RESOURCES-MIB::hrSystemMaxProcesses.0 = INTEGER: 0 ORNO-MIB::ornoOrWe504DeviceIndex.1 = INTEGER: 1 ORNO-MIB::ornoOrWe504Voltage.1 = INTEGER: 6.4 V ORNO-MIB::ornoOrWe504Current.1 = INTEGER: 6.5 A ORNO-MIB::ornoOrWe504Frequency.1 = INTEGER: 6.6 Hz ORNO-MIB::ornoOrWe504ActivePower.1 = INTEGER: 67 W ORNO-MIB::ornoOrWe504ReactivePower.1 = INTEGER: 68 VAr ORNO-MIB::ornoOrWe504ApparentPower.1 = INTEGER: 69 VA ORNO-MIB::ornoOrWe504PowerFactor.1 = INTEGER: .070 ORNO-MIB::ornoOrWe504TotalEnergy.1 = INTEGER: 71 Wh ORNO-MIB::ornoOrWe504DeviceIndex.2 = INTEGER: 2 ORNO-MIB::ornoOrWe504Voltage.2 = INTEGER: 7.2 V ORNO-MIB::ornoOrWe504Current.2 = INTEGER: 7.3 A ORNO-MIB::ornoOrWe504Frequency.2 = INTEGER: 7.4 Hz ORNO-MIB::ornoOrWe504ActivePower.2 = INTEGER: 75 W ORNO-MIB::ornoOrWe504ReactivePower.2 = INTEGER: 76 VAr ORNO-MIB::ornoOrWe504ApparentPower.2 = INTEGER: 77 VA ORNO-MIB::ornoOrWe504PowerFactor.2 = INTEGER: .078 ORNO-MIB::ornoOrWe504TotalEnergy.2 = INTEGER: 79 Wh End of MIB $ #snmpwalk -Cc   localhost .1 $ snmptranslate    .iso.org.dod.internet.private.enterprises.orno -Tp +--orno(69)    |    +--ornoMIB(0)    |    +--ornoWe504Table(504)    |  |    |  +--ornoOrWe504Entry(0)    |     |  Index: ornoOrWe504DeviceIndex    |     |    |     +-- -R-- Integer32 ornoOrWe504DeviceIndex(0)    |     |        Range: 1..255    |     +-- -R-- Integer32 ornoOrWe504Voltage(1)    |     |        Textual Convention: Tenths    |     +-- -R-- Integer32 ornoOrWe504Current(2)    |     |        Textual Convention: Tenths    |     +-- -R-- Integer32 ornoOrWe504Frequency(3)    |     |        Textual Convention: Tenths    |     +-- -R-- Integer32 ornoOrWe504ActivePower(4)    |     +-- -R-- Integer32 ornoOrWe504ReactivePower(5)    |     +-- -R-- Integer32 ornoOrWe504ApparentPower(6)    |     +-- -R-- Integer32 ornoOrWe504PowerFactor(7)    |     |        Textual Convention: Thousandths    |     +-- -R-- Integer32 ornoOrWe504TotalEnergy(8)    |    +--ornoWe505Table(505)       |       +--ornoOrWe505Entry(0)          |  Index: ornoOrWe505DeviceIndex          |          +-- -R-- Integer32 ornoOrWe505DeviceIndex(0)          +-- -R-- TimeTicks ornoOrWe505Update(1)          |        Textual Convention: TimeStamp          +-- -R-- TimeTicks ornoOrWe505Since(2)          |        Textual Convention: TimeStamp          +-- -R-- Integer32 ornoOrWe505Energy(3)

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


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


$ make clean rm -f ORNO-OR-WE-504-modbus ORNO-OR-WE-505-gpio ORNO-OR-WE-504-snmp ORNO-OR-WE-505-snmp ORNO-OR-WE-dumpy $ make -j cc -std=c2x -I/usr/include/modbus  -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-504-modbus.c   -o ORNO-OR-WE-504-modbus cc -std=c2x -I/usr/include/modbus  -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-505-gpio.c   -o ORNO-OR-WE-505-gpio c++ -std=c++20 -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-504-snmp.cpp   -o ORNO-OR-WE-504-snmp c++ -std=c++20 -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-505-snmp.cpp   -o ORNO-OR-WE-505-snmp cp ORNO-OR-WE-dumpy.sh ORNO-OR-WE-dumpy $ file ORNO-OR-WE-504-modbus ORNO-OR-WE-505-gpio ORNO-OR-WE-504-snmp ORNO-OR-WE-505-snmp ORNO-OR-WE-dumpy ORNO-OR-WE-504-modbus: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[xxHash]=a58765009c288441, with debug_info, not stripped ORNO-OR-WE-505-gpio:   ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[xxHash]=dff6cd7a988f007d, with debug_info, not stripped ORNO-OR-WE-504-snmp:   ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[xxHash]=1c805d687f14be15, with debug_info, not stripped ORNO-OR-WE-505-snmp:   ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[xxHash]=42917d88e82d6e4d, with debug_info, not stripped ORNO-OR-WE-dumpy:      POSIX shell script, ASCII text executable $ make clean rm -f ORNO-OR-WE-504-modbus ORNO-OR-WE-505-gpio ORNO-OR-WE-504-snmp ORNO-OR-WE-505-snmp ORNO-OR-WE-dumpy $ $ CPPFLAGS="-target arm-linux-gnueabi -Wno-atomic-alignment -Wno-unaligned-access" LDFLAGS=-L. make -j cc -std=c2x -I/usr/include/modbus  -target arm-linux-gnueabi -Wno-atomic-alignment -Wno-unaligned-access -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -L. -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-504-modbus.c   -o ORNO-OR-WE-504-modbus cc -std=c2x -I/usr/include/modbus  -target arm-linux-gnueabi -Wno-atomic-alignment -Wno-unaligned-access -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -L. -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-505-gpio.c   -o ORNO-OR-WE-505-gpio c++ -std=c++20 -target arm-linux-gnueabi -Wno-atomic-alignment -Wno-unaligned-access -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -L. -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-504-snmp.cpp   -o ORNO-OR-WE-504-snmp c++ -std=c++20 -target arm-linux-gnueabi -Wno-atomic-alignment -Wno-unaligned-access -D_GNU_SOURCE -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -g -Wall -Wextra -L. -flto=full -fuse-ld=lld -Wl,--as-needed -lrt -latomic -lmodbus   ORNO-OR-WE-505-snmp.cpp   -o ORNO-OR-WE-505-snmp cp ORNO-OR-WE-dumpy.sh ORNO-OR-WE-dumpy $ file ORNO-OR-WE-504-modbus ORNO-OR-WE-505-gpio ORNO-OR-WE-504-snmp ORNO-OR-WE-505-snmp ORNO-OR-WE-dumpy ORNO-OR-WE-504-modbus: ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[xxHash]=44fdf79bc38c0196, with debug_info, not stripped ORNO-OR-WE-505-gpio:   ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[xxHash]=74c95938f997db5b, with debug_info, not stripped ORNO-OR-WE-504-snmp:   ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[xxHash]=65f435484ede0393, with debug_info, not stripped ORNO-OR-WE-505-snmp:   ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.2.0, BuildID[xxHash]=e7cf566d96f8f12d, with debug_info, not stripped ORNO-OR-WE-dumpy:      POSIX shell script, ASCII text executable

(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):



You must log in to comment.

in reply to @nabijaczleweli's post:

idk, when i first tried the exe it gave me "wine mono not installed" (or something to that effect) and early-exited, and i only overcame that after msiexec /iing wine-mono-7.4.0-x86.msi (at which point it started enough to crash for fonts, and I haven't managed to overcome that). there may be problems with my procedure owing to the fact that im (a) stupid and (b) not a prolific wine user, so idk

well. i saw .exe so i tried wine :v

installing all 300M of mono-complete gave me a different error than just -runtime – https://lfs.nabijaczleweli.xyz/0015-cohost-images/2023-01-15-nabijaczleweli_1002162-gave-up-ran-their-e-screenshot.png – naturally, it doesnt say what the supported version is, im not enough of a C# enjoyer to know, and the exception is from a random address inside the program

running it in wine with wine-mono it still explodes on fonts in System.Windows.Forms.[...] in System.Drawing.FontFamily, and idk how id even tell it to just use whatever; under strace i see it opening every single font fc knows about and I have the fonts package so fuck knows which font it wants (well, except that theres a get_GenericSansSerif() in the call stack, but fuck knows what that means)

well, after finding the ENOENTs, i did ln -s /usr/share/wine/fonts /home/nabijaczleweli/.wine/dosdevices/c:/windows/Fonts which made it work(?!). well, it went to https://lfs.nabijaczleweli.xyz/0015-cohost-images/2023-01-15-nabijaczleweli_1002162-gave-up-ran-their-e-screenshot2.png (the last line does actually repeat every 60s, this is the only wine process), and "OleDb is not implemented." probably means that it can't open the accompanying .mdb MS Access database, so ultimately futile.