Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orno1p: wrong opcodes? #283

Open
andig opened this issue Sep 25, 2022 · 6 comments
Open

Orno1p: wrong opcodes? #283

andig opened this issue Sep 25, 2022 · 6 comments
Labels
bug Something isn't working

Comments

@andig
Copy link
Contributor

andig commented Sep 25, 2022

@ochykysh could you kindly double-check https://github.com/volkszaehler/mbmd/blob/master/meters/rs485/orno1p.go? It seems strange to have 3p values in the opcodes map for a 1p meter? Also seems as if not all opcodes are referenced by the producer?

Stumbled upon the by user report of evcc-io/evcc#4576

Originally posted by @andig in #129 (comment)

@andig andig added the bug Something isn't working label Sep 25, 2022
@ochykysh
Copy link
Contributor

(copy of comment in the original issue)

@andig The register codes are from the original PDFs

https://b2b.orno.pl/download-resource/26063/
https://b2b.orno.pl/download-resource/26064/

And yes, they do have 3p registers on a 1p meter...no idea why. I decided not to poll for registers that will be empty, so that's why data is not being collected from phase 2 and phase 3.

We could remove the references if you think it would be better.

@andig
Copy link
Contributor Author

andig commented Sep 25, 2022

Thank you, seems the confusion is due to the vendor. Main problem is that Power won't work on the 1p meter. Seems we should make Power an alias of PowerL1 here?

@ochykysh
Copy link
Contributor

If we do that, probably makes sense to do it for

VoltageL1 -> Voltage
CurrentL1 -> Current
PowerL1 -> Power
ReactivePowerL1 -> ReactivePower
ApparentPowerL1 -> ApparentPower
CosphiL1 -> Cosphi

Do we have some alias implementation already? Don't want to poll all of those registers two times unless I have to.

@andig
Copy link
Contributor Author

andig commented Sep 27, 2022

Do we have some alias implementation already?

We don't and it would probably not help. Problem seems to be that for the "official" registers the L1 measurements use different registers from the total measurements.

As the implementation is targeted at L1 meters my current approach would be:

  • comment all registers as "offical definition"
  • rename all L1 measurements to totals

Downside: we will no longer show L1 measurements in the UI. OR we duplicate them, but that would generate additional reads.

Seems we need to think about a proper solution a little more.

@ochykysh
Copy link
Contributor

Just a note: if we just rename them, we will break existing installations.
Too bad we can't return the set of values as a whole, that way we could easily add the alias implementation.

@RichieB2B
Copy link
Contributor

RichieB2B commented Dec 31, 2022

Too bad we can't return the set of values as a whole, that way we could easily add the alias implementation.

We and we should, as proposed in #255

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants