Services won’t start

[cmcMac]

On the help of Grok, I was able to temporarily get them to start i’m not sure what all it did. Really enjoyed my current work. Would like to use this alternative with home assistant.

[vegard1977]

Hi @cmcMac — glad you're enjoying it! Let's get those running properly.

Quick context: sampler.lua is the important one — it reads the ADE energy chips and feeds the queue that mqtt-streamer (already running for you) publishes to Home Assistant. Until sampler runs, the streamer has nothing to send. serial-reader.lua is only needed if you have a USB serial device plugged in (Arduino / ESP32 / AMS reader) — if you don't, it's fine to leave it stopped; it won't affect your HA energy data.

To see why sampler stops, run it in the foreground so the error is visible:

cd /data/lamarr
lua sampler.lua 1000 true
cat /var/log/sampler.log

Paste the output here. The usual causes are:

1. no model number in EEPROM — sampler can't read the board model, so it exits immediately.
2. ADE / I2C errors — the energy chips aren't responding on the I2C bus.

(If you also need serial-reader: cd /data/lamarr && lua serial-reader.lua — it'll print what config it's missing.)

"Grok got them started temporarily" usually means it launched them by hand, which lasts until the next crash or reboot. Once we fix the underlying error, hm (the health monitor) keeps them running on its own. Post the sampler output and we'll take it from there 👍

[cmcMac]

Repeats this.

Sun Aug 16 17:14:10 2026 WARN Logger: changing loglevel from DEBUG to INFO
Sun Aug 16 17:14:10 2026 INFO Starting Lamarr sampler...
Sun Aug 16 17:14:10 2026 INFO Attempting to load config from /data/hub-config.json
Sun Aug 16 17:14:10 2026 INFO Config revision 1766441268 loaded from /data/hub-config.json
Sun Aug 16 17:14:10 2026 INFO Sampling from 4 ADE chips
Sun Aug 16 17:14:13 2026 WARN Logger: changing loglevel from DEBUG to INFO
Sun Aug 16 17:14:13 2026 INFO Starting Lamarr sampler...
Sun Aug 16 17:14:13 2026 INFO Attempting to load config from /data/hub-config.json
Sun Aug 16 17:14:13 2026 INFO Config revision 1766441268 loaded from /data/hub-config.json
Sun Aug 16 17:14:13 2026 INFO Sampling from 4 ADE chips

cd /data/lamarr/&& lua serial-reader.lua

[vegard1977]

Thanks — that log tells us a lot. The sampler starts, loads config, prints "Sampling from 4 ADE chips", then dies and hm restarts it every ~3s. It's crashing right at ADE initialization — almost always one of the ADE energy chips not responding on the I2C bus.

The log file only shows the restart loop; the actual Lua error goes to the console. Run it in the foreground and paste the console output (the traceback), not the log file:

cd /data/lamarr
lua sampler.lua 1000 true 2>&1 | head -30

That traceback names the exact chip/register that fails.

If it is a dead or missing ADE chip, I have a patched ade.lua that makes the sampler skip the non-responding chip and keep sampling on the healthy ones instead of crash-looping — I hit exactly this on my own unit. We'll confirm from the traceback first, then I'll share it.

[cmcMac]

lua sampler.lua 1000 true 2>&1 | head -30

lua: ./queue.lua:23: attempt to compare nil with number
stack traceback:
./queue.lua:23: in function 'init'
sampler.lua:75: in main chunk
[C]: at 0x00009bc4

[vegard1977]

Good — that actually rules out the ADE chips. It's crashing earlier, in the SysV message-queue init that links the sampler to the streamer (queue.lua:23), before any ADE access. Something it expects — likely the IPC key from ftok, or the result of msgget — is coming back nil.

queue.lua is stock Lamarr code (not from my repo), so I need to see that line. Please paste:

sed -n '1,30p' /data/lamarr/queue.lua
lua -v

Since Grok "did something" earlier, it may have edited queue.lua or sampler.lua — this comparison failing at startup looks like a change to one of them. Line 23 will tell us exactly what's nil.

[cmcMac]

sed -n '1,30p' /data/lamarr/queue.lua

local bit = require 'bit'
local socket = require 'socket'

local sysvmsg = require 'posix.sys.msg'
local stat = require 'posix.sys.stat'
local mp = require 'MessagePack'

local queue = {}

-- contstants
queue.STREAMER_KEY = 1234
queue.LOAD_CONTROLLER_KEY = 5678
queue.LEGACY_KEY = 5678
queue.MSG_TYPE = 1
queue.MAX_MSG_SIZE = 2048
queue.MAX_QUEUE_ELEMENTS = 60 * 30
--- System V message queue size - note: reboot required for changes to take effect
queue.BUFFER_SIZE = queue.MAX_MSG_SIZE * queue.MAX_QUEUE_ELEMENTS

function queue.init(key)
local queueId, errmsg, errnum = sysvmsg.msgget(key, bit.bor(sysvmsg.IPC_CREAT, stat.S_IRUSR, stat.S_IWUSR))

if queueId < 0 then
print(string.format("ERROR - unable to get message queue: %s (%d)", errmsg, errnum))
return nil
end

return queueId
end

lua -v

LuaJIT 2.0.4 -- Copyright (C) 2005-2015 Mike Pall. http://luajit.org/

I have undone anything that grok helped with and started over so this is a fresh install I believe. I can start over again.
Grok had me add LEGACY_KEY to queue.lua and match the curb data format in mitt-streamer.lua.

Happy to start over again but it produced the same output.

Thanks for being so responsive. Once I get this working I have 4 more to do.

[vegard1977]

Perfect — that's the smoking gun. Line 23 is if queueId < 0, but when msgget fails this binding returns nil (not -1), so it crashes on the comparison before it can print the real error. So msgget is failing — we just can't see why yet.

Quick fix to reveal the reason — change that check to also catch nil:

  if not queueId or queueId < 0 then
    print(string.format("ERROR - unable to get message queue: %s (%d)", errmsg, errnum))
    return nil
  end

Then run lua sampler.lua 1000 true 2>&1 | head again — it'll now print the real errno (EACCES / ENOSPC / EINVAL…), which tells us exactly why the queue can't be created.

Also paste:

ipcs -q
sed -n '1,15p' /data/lamarr/queue.lua

That shows the existing message queues and how STREAMER_KEY is defined. My hunch: the streamer already holds the queue, or the SysV queue limit is maxed — the errno will confirm it. And 👍 on the 4 more units — once we nail this, it's the same fix on all of them.

[cmcMac]

luajit sampler.lua 1000 true 2>&1 | head -30

luajit: sampler.lua:76: attempt to compare nil with number
stack traceback:
sampler.lua:76: in main chunk
[C]: at 0x00009bc4
ERROR - unable to get message queue: msgget: Permission denied (13)

ipcs -q

------ Message Queues --------
key msqid owner perms used-bytes messages
0x0000162e 0 root 600 0 0
0x000004d2 32769 curb 600 0 0

sed -n '1,15p' /data/lamarr/queue.lua

local bit = require 'bit'
local socket = require 'socket'

local sysvmsg = require 'posix.sys.msg'
local stat = require 'posix.sys.stat'
local mp = require 'MessagePack'

local queue = {}

-- contstants
queue.STREAMER_KEY = 1234
queue.LOAD_CONTROLLER_KEY = 5678
queue.LEGACY_KEY = 5678
queue.MSG_TYPE = 1
queue.MAX_MSG_SIZE = 2048

[vegard1977]

There it is — msgget: Permission denied (13) (EACCES). Your ipcs -q shows exactly why:

key         owner   perms
0x000004d2  curb    600    ← STREAMER_KEY 1234, owned by curb  ✓
0x0000162e  root    600    ← LEGACY_KEY 5678, owned by ROOT    ✗

The sampler drops to user curb at startup (daemonize.seteuid("curb")), then attaches to both queues. STREAMER is owned by curb — fine. But the LEGACY queue (key 5678) is owned by root, perms 600, so the curb user is denied. That's the crash on the second queue.

It's a stale root-owned queue left over from an earlier run as root (or from Grok's poking). Remove it and let the sampler recreate it as curb:

ipcrm -q 0

(msqid 0 is the root-owned 0x0000162e in your ipcs.) Then let hm restart the sampler (or run it once manually). It'll recreate key 5678 as curb, so both queues are curb-owned → no more EACCES.

Verify:

ipcs -q      # both queues should now show owner "curb"

If that root-owned queue keeps reappearing, something is creating it as root before the sampler does — then the clean fix is a one-line patch so the sampler skips the legacy queue entirely (the legacy streamer is retired in this setup; only the STREAMER queue matters for MQTT/HA). Say the word and I'll give it to you.

[cmcMac]

sure whatever is needed to fix it.

[cmcMac]

ipcs -q

------ Message Queues --------
key msqid owner perms used-bytes messages
0x000004d2 32769 curb 600 0 0

I will be using HA in the future. I got it now to keep both permissions as root
'lua sampler.lua 1000 true 2>&1 | head -30'
is showing data flowing it looks like
'{"t":1786913672,"g":[{"t":1.6572608947754,"f":59.994140625,"tg":1.6454676389694,"v":120.53876789074'
The webUI still looks the same as the screenshot and no CT data displayed.

[cmcMac]

ps | grep -E "sampler|serial-reader"

894 root {curb_hm_process} /bin/sh /usr/local/bin/curb_hm_process.sh ./serial-reader.lua
931 root lua ./serial-reader.lua
2022 curb luajit sampler.lua
2031 root {curb_hm_process} /bin/sh /usr/local/bin/curb_hm_process.sh sampler.lua
2038 curb luajit /data/lamarr/sampler.lua
2053 root luajit serial-reader.lua
2473 root grep -E sampler|serial-reader

[cmcMac]

Got it displaying data now but what is being reported seems off

Summary of fixes applied

The main problems were:

1. SysV message queue permission issue A root-owned queue (key 0x0000162e / LEGACY_KEY 5678) was left behind. After the sampler dropped privileges to the curb user it got EACCES and crash-looped. Fixed temporarily with ipcrm -q 0. The queue no longer needs to exist for this setup.

2. mqtt-streamer was listening on the wrong queue The sampler writes to STREAMER_KEY (1234). mqtt-streamer.lua was still trying to read from LOAD_CONTROLLER_KEY / LEGACY_KEY (5678). Changed the init line to:

   Lua

   local qid = queue.init(queue.STREAMER_KEY)

3. Data format mismatch in mqtt-streamer.lua This Curb’s samples use different field names than the ones expected by the stock mqtt-streamer.lua:

   Stock field | Actual field on this unit -- | -- sample.group | sample.g group.vrms | group.v group.channel | group.c ch.watthr | ch.w ch.irms | ch.i ch.powerFactor | ch.p

   Applied the corresponding substitutions so the script can parse the samples.

After these changes latest.json is written correctly and the energy web UI shows live circuit data. Currently testing that the changes survive a reboot.

[vegard1977]

🎉 Nice work — you nailed all three, and live circuit data in the energy UI means the whole pipeline (sampler → queue → streamer → latest.json → web) is flowing.

On "will it survive a reboot?" — heads up: your sampler still writes to both queues (STREAMER_KEY 1234 and LEGACY_KEY 5678). You've pointed the streamer at STREAMER_KEY, so LEGACY is now doing nothing — but if that root-owned 5678 queue gets recreated at boot, the sampler will hit the same EACCES on it and crash-loop again, even though nothing reads it.

Durable fix (so you never need ipcrm again): make the sampler skip the legacy queue too. Find where it builds its output-queue list — it'll have both keys, e.g.:

local OUTPUT_QUEUE_KEYS = { queue.STREAMER_KEY, queue.LEGACY_KEY }

and drop the legacy one:

local OUTPUT_QUEUE_KEYS = { queue.STREAMER_KEY }

Now the sampler only touches the curb-owned STREAMER queue → no permission conflict, survives reboots, no ipcrm needed.

On the field-name substitutions (g/v/c/w/i/p vs group/vrms/channel/watthr/irms/powerFactor) — that's a firmware-version difference between your Curb and mine; good catch. I'm folding an auto-detect for both formats into the repo streamer so your other 4 units just work without editing. Out of curiosity, which firmware/model is this unit? (helps me handle it generically.)