Odoo metering, energy and device integrations
Why these belong on one page
A meter feed and an attendance clock look nothing alike until you watch them fail. Then they are the same problem.
Transactional integrations move a record that already exists and is final. These do not. A meter back-fills yesterday’s reads at nine tomorrow morning. A device that lost its network for an afternoon replays everything at once when it returns. A rate publishes for an hour that has already been consumed. None of that is an error condition. It is the normal operation of the source, and any design that treats a late read as an exception will spend its life raising alerts nobody can act on.
What makes it expensive is what sits downstream. You invoice on this data. A read that lands after the billing run does not get to be a footnote.
So ordering guarantees, back-fill handling and idempotent writes are the architecture here rather than the remediation. Every write assumes it will arrive twice, and a correction to a period already invoiced has a defined behaviour decided before any code is written.
Energy rates and meter reads
Hourly area-based rates from Nordpool. Meter readings, measure points and hourly reads from Elvaco. Both feeding an Odoo billing engine we built, which raises invoices against consumption and exposes usage to customers through a portal.
Billing does not accept “late” as an explanation. The design question was not how to call two APIs. It was what happens when a read for a settled period arrives after the invoice has gone out, and how anyone finds out that it did. The accounting side of the same engagement runs through PowerOffice Go and Peppol.
- Sources
- Nordpool hourly area rates · Elvaco meter reads, measure points, hourly reads
- Downstream
- Custom Odoo billing engine, customer usage portal
- Handling
- Ordering guarantees, back-fill, idempotent writes, defined behaviour for post-invoice corrections
- Delivered for
- A Nordic energy operation. End client under NDA.
- Availability
- Built to order. Not a published module.
Biometric attendance devices
ZKTeco attendance devices reporting into Odoo: a scheduled pull of punch logs, so the punch at the door is a searchable record instead of a file export at the end of the week.
Device integration is where the network is least reliable and the users are least forgiving. A clock that buffers, then dumps, is the failure mode on this category page. The ZKTeco landing is the ingest: device-log id skip, structured rows, credentials you hold.
Receipt and label hardware
Custom receipt and label printer integration, including a thermal receipt printer running a protocol with no existing Odoo integration behind it.
Printers are the integration nobody scopes and everybody needs. The work is rarely the printing. It is knowing whether the ticket came out, at the right station, in the right script, and what a reprint means when the first document was already numbered or already posted. We evaluated Odoo’s IoT Box for a multi-outlet print estate and left it, because the network would not carry it. Print runs through a dedicated print server instead.
Print inside a live ordering estate sits on Ordable →
What holds across all three
Every integration on this page is judged on the days the source misbehaves rather than the day it was connected. So the shape is the same in each case. Ordering and duplicate handling decided before code. Idempotent writes throughout. A reconciliation pass that compares both sides on a schedule and raises the delta instead of absorbing it. Failed messages in a queue you can inspect, not a log line that scrolled past.
What we don’t do
Sell you hardware, resell meter or market data access, or hold your device credentials. We also won’t build against a device with no documented protocol and no test unit in our hands. Reverse-engineering a printer we cannot power on is not an estimate, it is a guess with an invoice attached.
We have delivered 20+ integrations across 12+ active geographies. Metering, energy and device work stays bespoke; payments are the part of the category we have published.
Integration engineering · ZKTeco · Banking & Finance · Odoo implementation
What is the feed, and what does it bill?
Tell us the source, how often it publishes, and whether money depends on it. Those three answers decide the architecture, and we can size the work from them in one reply.