SmartMeterOSGP Binding

Blinding to communicate with a smart meter via the C12.18 and C12.19 protocols. These protocols are part of the Open Smart Grid Protocol (OSGP) family of protocols.
Typically these are interfaced via an IR optical interface.
The binding is tested with Echelon 83331-3I and 83334-3I and with IR probe from Weidmann Elektronik.

Changelog

Version 0.1

  • initial release

Version 0.2

  • Added support for setting a logoff Interval
  • Fixed to work better with 83334-3I

Version 0.3

  • Updated to OH 4
  • Added option to allow some Idle time every day,

Resources

https://github.com/kennetn/openhab-addons/releases/download/v4.0.0-beta.1/org.openhab.binding.smartmeterosgp-4.0.0-SNAPSHOT.jar

Hi Kennet,

I am currently integrating ANSI C12.18 support for an Echelon/NES electricity meter into the AMS Reader firmware.

I based the session handling on your SmartMeterOSGP implementation:

  • polling approximately every 2 seconds,
  • keeping the C12.18 session open between reads,
  • sending LOGOFF and TERMINATE after a limited session duration,
  • and allowing an idle period before reconnecting.

The local C12.18 reading works correctly. However, since running my implementation, my grid operator/provider OVE no longer appears to receive meter data through the normal OSGP/PLC connection. When I stop the optical C12.18 reader, the central communication appears to recover.

Did you ever observe that an active or frequently reopened C12.18 session on an Echelon 83331/83334 meter interfered with its OSGP/PLC communication to the data concentrator?

I am particularly interested in why you added:

  • the configurable logoff interval,
  • the periodic LOGOFF/TERMINATE,
  • and the daily idle period.

Were these measures added because of a known or observed conflict with remote meter communication, or only to improve the stability of the optical C12.18 connection itself?

If you encountered a similar issue, could you share which polling interval, maximum session duration, and idle duration worked reliably without affecting the utility’s remote readings?

Thank you for any details you can provide.

Hi Markus

It has been quit some time since I looked at this, so I do not remember all the details.

I do remember that I was seeing issues with the data concentrator not getting updated information and this was why I added the idle every night.

I do not remember what settings I tested but I am using the default settings (idle at 2:10:00 and 8 minutes) myself and this has been working as fare as I know.

For the configurable logoff interval I am a bit unsure, I guess this was to reduce the occasional errors that I was seeing. But I still have occasional errors.

Guess I should have written a bit more down :slight_smile: .