No output for model sunspec 213

[BenGig]

With PR #191 support for meter float model sunspec 213 was introduced. I have a Fronius Smart Meter 63A which reports as such a model.

With mbmd inspect, I get all measurement correctly:

> docker run --rm -p 8080:8080 volkszaehler/mbmd  inspect -d SUNS:240@symo:502
2021/04/16 21:51:34 config: creating TCP connection for symo:502
--------- Model 1 common ---------
Mn            Fronius    string
Md    Smart Meter 63A    string
Opt          3.16.7-1    string
Vr                2.9    string
SN           18410005    string
DA             240.00    uint16
Pad            0x00d5    pad
--------- Model 213 ac_meter ---------
A                            3.05    float32
AphA                        0.929    float32
AphB                         1.48    float32
AphC                        0.641    float32
PhV                     244.23334    float32
PhVphA                      243.7    float32
PhVphB                      243.7    float32
PhVphC                      245.3    float32
PPV                     423.03333    float32
...

With mbmd run, connection is established, the device is again detected correctly, but no values are reported:

> docker run --rm -v $(pwd)/mbmd.yml:/etc/mbmd.yaml -p 8080:8080 volkszaehler/mbmd run -v
2021/04/16 22:17:33 mbmd 0.13 (fa6b574)
2021/04/16 22:17:33 config: using /etc/mbmd.yaml
2021/04/16 22:17:33 config: creating TCP connection for symo:502
2021/04/16 22:17:33 config: declared device SUNSPEC:240.0
2021/04/16 22:17:33 httpd: starting api at 0.0.0.0:8080
2021/04/16 22:17:35 initialized device SUNSPEC1.240: {SUNSPEC Fronius Smart Meter 63A 3.16.7-1 2.9 18410005 0}
^C2021/04/16 22:21:45 received signal - stopping
2021/04/16 22:21:45 stopped

Output stops until interrupted with CTRL-C.

[andig]

@BenGig could you provide remote access for debugging?

[BenGig]

Do you have the option to use Wireguard? I could give you a config, and provide a devel environment in a VM.

[andig]

Wireguard would work. Access to the inverter would be good- why the VM?

[BenGig]

Nevermind the VM, the first idea is rarely the best. May I use your mail address from your profile, for the details?

[andig]

I can replicate the behaviour. Will investigate.

[andig]

Bei mir sieht das so aus:

Was fehlt Dir denn jetzt konkret?

[andig]

ping @BenGig

[BenGig]

Sorry, Abgabetermin@Work

Browserproblem.

Ich hab nacheinander meine Standards Brave und Waterfox versucht, dann Edge und Firefox. Nur FF hat die Daten angezeigt. Bei den anderen: der statische Teil der Webseite lädt, bleibt dann auf "Measurements: loading...".

[BenGig]

Korrektur: auch Firefox zeigt nichts an; Noscript war noch aktiv. Was ich gesehen hab waren die Platzhalter {}

[andig]

Kann ich nicht reproduzieren. Geht mit Safari und Chrome wunderbar.

[BenGig]

JS deaktiviert:

JS aktiv:

[BenGig]

Seltsam ist, dass auch MQTT zwar /mbdb/status:connected meldet, aber sonst nichts, kein /mbmd//*.

mbmd version : 0.13 commit : fa6b574 go version : go1.13 go compiler : gc platform : linux/amd64

[andig]

mbdb/status:connected meldet, aber sonst nichts, kein /mbmd//*.

Also root bei mqtt ist mbmd, nicht /mbmd. Ebenso ist Wildcard mbmd/# und nicht /mbmd//*.

[BenGig]

War nur schnell hingeschrieben; so sieht es aus, mehr als "connected" kommt nicht:

[snh]

I suspect I'm experiencing the same problem. Like @BenGig, inspect returns values fine, but run doesn't seem to ever get any values. It doesn't seem to be a browser issue in my case, as run works fine against the inverter itself, just not the connected energy meter.

$ docker run --rm -it -p 8080:8080 volkszaehler/mbmd inspect -a 10.9.136.32:502 -d FRONIUS:240
2023/01/16 20:18:18 config: creating TCP connection for 10.9.136.32:502
--------- Model 1 common ---------
Mn            Fronius    string
Md   Smart Meter 50kA    string
Opt          3.23.6-1    string
Vr               3.04    string
SN           <removed>    string
DA             240.00    uint16
Pad            0x00d5    pad
--------- Model 213 ac_meter ---------
A                            8.72    float32
AphA                         1.62    float32
AphB                         1.98    float32
AphC                         5.12    float32
PhV                     239.23334    float32
PhVphA                      239.8    float32
PhVphB                      238.8    float32
PhVphC                      239.1    float32
...

No errors from the run:

$ docker run --rm -it -p 8080:8080 volkszaehler/mbmd run -a 10.9.136.32:502 -d FRONIUS:240
2023/01/16 20:12:19 mbmd 0.13 (fa6b574)
2023/01/16 20:12:19 config: creating TCP connection for 10.9.136.32:502
2023/01/16 20:12:19 config: declared device FRONIUS:240.0
2023/01/16 20:12:19 httpd: starting api at 0.0.0.0:8080
2023/01/16 20:12:20 initialized device FRONIUS1.240: {FRONIUS Fronius Smart Meter 50kA 3.23.6-1 3.04 <removed> 0}

But just shows Loading... in the UI:

API also returns nothing:

$ curl http://<ip>:8080/api/last
all meters are inactive

If I enable --raw, I see the following at the end:

2023/01/16 22:17:41 initialized device FRONIUS1.240: {FRONIUS Fronius Smart Meter 50kA 3.23.6-1 3.04 <removed> 0}
2023/01/16 22:17:46 modbus: closing connection due to idle timeout: 5.000419038s

[snh]

Made some progress, the latest Docker image is 2 years old, since that is when the last release of mbmd appears to have been cut, so predates https://github.com/volkszaehler/mbmd/pull/191.

Building the Docker image from the latest version of the master branch got me a different error.

docker build -t volkszaehler/mbmd:devel https://github.com/volkszaehler/mbmd.git

And then using volkszaehler/mbmd:devel as the image in the docker run invocation.

I now get the following error instead:

2023/01/16 22:30:37 modbus: send 00 01 00 00 00 06 f0 03 9c 40 00 02
2023/01/16 22:30:37 initializing device FRONIUS1.240 failed: read tcp 172.17.0.3:50088->10.9.136.32:502: i/o timeout

FRONIUS1.1 is still working fine for the inverter itself.

inspect also fails with the same error now for FRONIUS1.240, whereas before when using 0.13 it returned values.

@andig Any plans for a new release soon, as I see a lot of improvements have been made since 0.13?

/cc @bengig

[snh]

Curious, docker build -t volkszaehler/mbmd:devel https://github.com/volkszaehler/mbmd.git#59dcc46d62d4d0169e430223c949810112ea26f3, which is the merge commit for https://github.com/volkszaehler/mbmd/pull/191, works fine for FRONIUS1.240 with both inspect and run.

So there seems to be a regression impacting this specifically between when https://github.com/volkszaehler/mbmd/pull/191 was merged and now. I'll see if I can narrow in on it the relevant PR.

[andig]

I guess I should automate the release process...

[snh]

I think I've narrowed it down to https://github.com/volkszaehler/mbmd/pull/265, as the immediately preceding commit of 7251dd80a3fb8cd49a3bb50c43207a03d0f7ffbd is fine, with a1401c1f7c7dab43910453c790fc9973e5274832 being the commit where the i/o timeout error crops up.

It seems the default of 300ms introduced by that PR isn't long enough in this specific case, though --timeout 1s seems to work fine from some quick testing.

[tobima]

Looks like RTU and TCP had different values for the timeout before #265: https://github.com/volkszaehler/mbmd/blob/870b3b92b81ec66ec4265fa2589851fb701f6fc7/meters/tcp.go#L21 It was 1s TCP and 300ms RTU. https://github.com/volkszaehler/mbmd/blob/870b3b92b81ec66ec4265fa2589851fb701f6fc7/meters/rtu.go#L36

The PR #265 was initial only about RTU and included later TCP, too. https://github.com/volkszaehler/mbmd/pull/265#issuecomment-1164712909

[snh]

Thanks @tobima, I couldn't find any other reports of issues post this PR, so I suspect 300ms is still plenty for most TCP cases.

I suspect part of the reason it is an issue here is that I'm talking to a Fronius Inverter using Modbus TCP which is then having to talk RTU to the connected Smart Meter, so a bit of latency is introduced by this double hop/translation. This would also explain why querying the Inverter at FRONIUS1.1 is fine, and it's only the Power Meter at FRONIUS1.240 that experiences the problem.

[tobima]

Issue #277 was caused by the regression after this PR, too. The issue was closed after the reporter used the timeout parameter.

I see here an issue with the documentation. Perhaps we should add a troubleshouting section to the Readme.md mentioning the timeout parameter to make this parameter more visible.