Wie sind die Öffnungszeiten?

Montag 07:30 - 17:00 Dienstag 07:30 - 17:00 Mittwoch 07:30 - 17:00 Donnerstag 07:30 - 17:00 Freitag 07:30 - 17:00

Wie lautet die Website?

https://www.moebus-engineering.de/

Möbus Engineering GmbH, Adam-Opel-Straße 3, Trebur (2026)

16/09/2026

Save the date: we will be exhibiting at E-world energy & water 2027 in Essen — 16 to 18 February, Hall 4, Stand 4H126, in the Innovation Area.

Five months ahead of time, because the meetings that are worth anything at a trade fair are the ones agreed beforehand. The rest is corridor traffic.

What we will have at the stand:

1. Hardware you can hold. The LI Node Z18 — D4i-certified, Zhaga Book 18 — to open, turn over and inspect. The laser-marked identification, both socket positions, the actual build rather than a render.

2. The platform, live. Switching schedules, per-luminaire dimming, telemetry and fault events on a running installation — not a slide deck of screenshots.

3. The ExplorerKit. What a pilot on your own segment actually involves: scoping, commissioning, the evidence package you take into a budget round — and how quickly it can start.

4. Straight answers on tender wording. Bring your draft specification. We will go through the clauses that decide interoperability, acceptance criteria and what happens at re-tender.

Utilities and operators are at E-world anyway. We would rather spend twenty focused minutes on your network than hand over another brochure.

→ Want a slot at Stand 4H126? Comment or DM us and we will block a time — the calendar fills up from January.

09/09/2026

We'll be at The Things Conference in Amsterdam on 22 September — and these are the questions we'd like to argue about.

Municipal street lighting is one of the largest LoRaWAN estates a city will ever operate: thousands of nodes, a twenty-year service life, public safety attached to it. Three topics decide whether that works — and all three sit on the line between the network operator and the device manufacturer.

1. Where network responsibility ends and device responsibility begins. Coverage planning, gateway density and antenna permissions belong to the operator; join behaviour, retry policy and power budget belong to the manufacturer. Most rollout surprises live exactly on that line — and every one of them is cheaper to resolve before the tender than after the first thousand poles.

2. Behaviour at population scale. One node joining is a demo. Thousands of nodes joining after a coordinated power-on is an engineering problem: duty-cycle limits, jitter windows, backoff policy. We think those numbers belong in acceptance criteria, not in a datasheet footnote.

3. Interoperability that survives re-tendering. D4i on the protocol side, Zhaga Book 18 on the mechanical side — so a node bought in 2026 can be replaced by a different manufacturer's node in 2034 without reopening the luminaire contract.

We build the controllers; operators run the networks. The conversations worth having are where those two views meet — and a conference is one of the few places they actually do.

→ If you're in Amsterdam on the 22nd: let's talk. Twenty minutes, a coffee, no pitch. Comment or DM and we'll fix a time in advance.

02/09/2026

Permanent marking, not stickers: how a controller keeps its identity for 15 years on the pole.

In production, a sticker is the easy answer: print the serial, stick it on, done. Which is exactly why stickers sit on millions of devices — and why maintenance crews curse them a decade later. UV in summer, frost in winter, condensation year round: the label fades, peels, disappears. And with it, the device's identity.

That's why we laser-engrave everything directly into the LI Node housing: serial number, DevEUI, QR code, conformity marks. As durable as the housing itself.

Why this belongs in a tender, not just in a datasheet:

1. The failure mode is silent. Nobody notices an unreadable label until year 12, when a technician stands at the pole and has to guess, dismount or look up what device is up there. A production shortcut becomes a recurring operating cost.

2. Machine-readable beats legible. A QR code scanned from the bucket — or from the ground — links the physical device to its asset record: firmware state, service history, radio parameters. No transcription, no typos, no wrong-device swaps.

3. Identity is a lifecycle requirement. Certification data, warranty cases and audits all reference the device ID. An ID that outlives the sticker is not cosmetic — it is the anchor of every record you will ever produce about that luminaire.

Spec wording we recommend: "Device identification (serial number, DevEUI, machine-readable code) shall be permanently marked on the housing — laser-engraved or equivalent — and shall remain legible and scannable for the specified service life."

→ Want our full marking and traceability wording for a tender? Comment "spec" or DM us.

26/08/2026

Citizen acceptance is a planning factor — not a communications afterthought.

Smart lighting changes what residents see every night. Adaptive dimming in particular triggers predictable questions: Why is my street darker at 2 a.m.? Is this safe? Who decided this? Operators who can answer these before they are asked run calmer rollouts — and councils approve faster when constituents understand the change.

What experience says belongs in the plan:

1. Explain the logic, not the technology. "Light follows use: full light when someone is there, reduced light when nobody is" lands better than any protocol name. One sentence, repeated everywhere.

2. Lead with what residents gain. Less light pollution and calmer nights, insect- and sleep-friendly lighting, lower energy cost for the municipal budget — these are resident benefits, not vendor features.

3. Make safety verifiable. Publish the dimming schedule and the rule that presence restores full light. Fear of dark streets shrinks when the behaviour is predictable and documented.

4. Give complaints a fast lane. A reporting channel plus automatic fault detection means a dark luminaire becomes a ticket — ideally before a resident calls. Response speed is the strongest acceptance argument there is.

5. Keep the evidence. Per-luminaire event logs answer "why was it dark on Tuesday?" with data instead of assurances — for citizens, councils and local press alike.

Acceptance is not won in the council meeting. It is won on the street, one explained change at a time.

→ Want our citizen-communication one-pager for dimming projects? Comment "onepager" or DM us.

19/08/2026

Five pitfalls to clear before a smart-lighting rollout — all avoidable at tender stage.

These come up again and again in conversations with network operators and municipal utilities. None of them is exotic; all of them are cheap to fix on paper and expensive to fix on the street.

1. Antenna permissions. If external antennas cannot be mounted on certain structures, the whole radio plan shifts: more gateways, different antenna choices, new site agreements. Clarify what is permitted before the network is designed — not after.

2. Gateway planning from geometry, not datasheets. Range figures from a lab say little about your streets. Coverage follows building density, vegetation and mounting heights. Require a coverage plan based on the actual deployment area — and a field verification step.

3. No small-scale test. A lab bench or a single street segment answers most integration questions for a fraction of the cost. Skipping straight to the full batch means discovering those answers at rollout speed, with a crew on the clock.

4. Devices arriving unconfigured. Every parameter set by hand on the street costs crew minutes and invites errors — multiplied by thousands of poles. Order devices pre-parameterized: keys, radio settings and profiles loaded before delivery.

5. No written acceptance criteria. Without measurable targets — join rates, commissioning windows, fault-reporting latency — a pilot is a demo and an acceptance test is an opinion. Define the numbers before the first pole is touched.

The pattern: every one of these is decided before the first controller hangs on a mast. That's where a tender earns its money.

→ Want the full pre-tender checklist? Comment "checklist" or DM us.

12/08/2026

The first ExplorerKits are in the field — and more are available now for utilities and municipalities.

Launch interest is easy; field evidence is what decisions are built on. That's what these kits are for: each one contains 3–10 connected controllers plus pre-configured platform access and guided onboarding — enough to take a real test segment live in your own network.

What a structured pilot with the kit looks like:

1. Scoping — before hardware ships. Segment selection, network coverage check, success criteria agreed in writing. A pilot without defined criteria is a demo.

2. Installation and commissioning. Zhaga plug-and-play mounting, nodes provisioned, segment live on the platform — typically without specialist tooling.

3. Operation by your team. Switching schedules, per-luminaire dimming, telemetry and fault events — run in your daily routine, not in a vendor demo account.

4. Evidence package. Energy figures, event logs, QA reports — export-ready for your council meeting, your budget round, your tender file.

The goal of the pilot is not a purchase order. It's a decision your team can defend — with data from your own streets.

ExplorerKits are available now. → Want one for your network? Request your ExplorerKit and we'll scope the pilot with you — link in the comments.

05/08/2026

One tender, two scorecards: utilities and municipalities measure lighting success differently — a good spec serves both.

Utilities and operators think operationally: maintenance effort, remote monitoring, knowing about an outage before the first citizen calls. Municipalities think in budgets and programmes: energy, CO₂ balance, funding eligibility. Same street, same luminaire — two definitions of success. A tender that encodes only one of them creates friction for years.

Five requirements that pay into both scorecards:

1. Per-luminaire energy metering (D4i data). Municipal side: documented kWh and CO₂ reduction for reporting and funding evidence. Operator side: load monitoring and anomaly detection — from the same data field.

2. Automatic fault reporting with location and timestamp. Operator: dispatch instead of search drives. Municipality: availability becomes a measurable, citizen-facing quality figure.

3. Dimming profiles with an audit trail. Municipality: energy-programme compliance, demonstrable when questioned. Operator: one managed change process instead of per-pole visits.

4. Exportable evidence (reports, event logs, QA heatmaps). Municipality: funding documentation. Operator: acceptance tests and warranty cases — one export, two uses.

5. Open standards (DALI-2/D4i, Zhaga, LoRaWAN). Both sides: procurement freedom at re-tender — the one KPI everyone shares.

The pattern behind all five: each requirement produces one data stream that both scorecards read differently. That's what "one platform, value for everyone" has to mean in a spec — not a compromise, a superset.

→ Drafting a tender and want our requirement block covering both perspectives? Comment "spec" or DM us.

29/07/2026

Two Zhaga sockets on a luminaire: why we recommend specifying both — even if you only need one today.

Zhaga Book 18 defines the mechanical interface (socket, dimensions, pins, sealing); DALI-2/D4i defines the language spoken across it. Together they make control and sensor modules plug-and-play across manufacturers. So the real specification question is not whether to use the standard — it's how many sockets to require.

Four reasons to put two sockets in the spec:

1. Function separation without conflict. The top socket typically carries the communication/control node; the bottom socket faces the road for motion and presence detection. Two positions, two functions — nothing competes for one mount point.

2. Retrofit at component cost, not luminaire cost. A socket specified today is a screw-on upgrade in year six; a missing socket is a new luminaire. The marginal cost at purchase is small; the option value across a 20-year asset is not.

3. Network-level sensing, not per-pole sensing. Modules interact across luminaires: on a cycle path, motion detection in the first and last luminaire is enough — the light runs ahead of the rider and dims down behind. Fewer sensor modules, full coverage — but only if the sockets exist where the geometry needs them.

4. Mixed-vendor freedom at every step. Book 18 + D4i means any conformant module fits any conformant socket. You can add a third-party sensor in 2030 without touching the 2026 luminaire contract.

Spec wording we recommend: "Luminaires shall provide two Zhaga Book 18 receptacles (top and bottom), wired per D4i, both available for field retrofit."

→ Want the full wording block for Zhaga/D4i requirements? Comment "spec" or DM us.

22/07/2026

The LI Node Z18 is now D4i-certified. Here's what that changes in a tender.

D4i is the DALI-2 extension for IoT-ready outdoor luminaires: it standardises how driver, sensor and control node exchange power and data inside the luminaire. Certification means the implementation has been independently tested against the specification — not self-declared. The Z18 is now listed in the DALI Alliance product database, where every certified DALI-2/D4i product can be publicly verified.

What certification buys you in procurement:

1. Verifiable, not claimed. "D4i-ready", "D4i-compliant", "DALI-based" — those are marketing terms. Certified products appear in the public DALI Alliance database; requiring the listing turns a brochure claim into a checkable acceptance criterion.

2. Interchangeability by standard. A certified node works with any certified D4i driver — across manufacturers, today and at re-tender. That is the technical basis for avoiding vendor lock-in across a luminaire's 20-year life.

3. Data you can rely on. D4i defines standardised memory banks for energy metering, diagnostics and asset data — same fields, same format, from every conformant driver. Monitoring stops depending on vendor-specific interpretations.

4. Tested edge cases. Certification exercises bus timing, error handling and unexpected states — the corner cases that never show up in a lab demo and always show up in the field.

Spec wording we recommend: "Control nodes shall be D4i certified and listed in the DALI Alliance product database at the time of bid submission."

15/07/2026

New whitepaper: what LED street-lighting conversion really saves in maintenance — energy savings excluded.

Everyone quotes the energy savings of LED. The second lever — maintenance and upkeep — is rarely put on the table honestly. So we did: with official guides, municipal project reports, manufacturer data and international programmes.

What the sources show:

→ Old lamps tie up the depot. Mercury-vapour lamps are replaced about every 2 years, sodium-vapour every 4–5 — each swap a crew, a bucket truck and traffic management. LED runs >100,000 h (≈ 20+ years) at under 1%/year failure: no lamp change, only cleaning and the mandatory inspection.

→ Documented maintenance reductions of −40% to −80% on old stock (US DOE/Maryland; Seattle City Light −64%; Erdmannhausen −40%). Our recommended planning assumption: −50% vs sodium-vapour — not "maintenance-free".

→ At 4,000 light points that is roughly €40,000–100,000/year of plannable relief (10–25 €/point/year, energy excluded).

What we kept honest:

→ The DGUV-V3 electrical inspection (every 4 years) stays — with LED too.
→ Against well-maintained sodium-vapour, the saving can approach zero; the big percentages apply to old stock.
→ Controller benefits are mostly operational (fault reports instead of search drives) and belong in the process case, not always in euros.
→ Software licence and follow-on cost belong in the amortisation.

And it's fundable: Germany's BMUV municipal guideline (NKI) co-funds LED refurbishment, at a higher rate for municipalities under budget consolidation.

→ Want the full whitepaper — 6 pages, every figure sourced (German)? Comment "whitepaper" or DM us and we'll send it.

Möbus Engineering GmbH

16/09/2026

09/09/2026

02/09/2026

26/08/2026

19/08/2026

12/08/2026

05/08/2026

29/07/2026

22/07/2026

15/07/2026

Adresse

Öffnungszeiten

Telefon

Website

Benachrichtigungen

Verknüpfungen

Teilen

Kategorie

Antrag auf Entfernung des Eintrags

Montag	07:30 - 17:00
Dienstag	07:30 - 17:00
Mittwoch	07:30 - 17:00
Donnerstag	07:30 - 17:00
Freitag	07:30 - 17:00