I'm currently testing DLMS communication over Android devices, and I've noticed that some VPNs cause the connection to drop or timeout intermittently when trying to read meter data remotely.
After several trials, I found that using Stag VPN actually resolves the issue. The communication remains stable and meter responses are consistent, even when routed through the VPN. I’m curious—has anyone else here tried DLMS/GXDLMS communication over a VPN? What’s your experience?
Any insights or alternative setups that work reliably would be appreciated.
Hi everyone, I’m prototyping a smart meter interface using an ESP32 to read DLMS/COSEM data over RS-485 and then relay that information via MQTT. For inspiration on reliable multi-node communication, I found this guide on ESP-NOW peer-to-peer networking really insightful: https://www.theengineeringprojects.com/2022/01/esp-now-protocol-with-es…
Hello, wanted to ask a question, maybe you will have some insights.
We are trying to find a solution to launch DLMS over Lorawan. One thing is that our product is battery-powered water meter.
I have questions:
1. Maybe you have real life examples that this was done before?
2. time / Duty cycle - this time is very strict in lorawan, how it is possible to overcome this barrier when DLMS handshake takes up to 6-12 telegrams?
BLE communication and reading of current values (without association) work correctly on all meters.
DLMS association (SNRM + AARQ) over BLE works only with the LGZ meter — the meter responds to chunked requests, and we receive replies successfully.
However, on other meters, the same association flow over BLE (sending the association request in chunks) fails — we do not receive any response after sending the AARQ.
Over USB/serial (using the same authentication level LOW), all meters respond correctly to the association request.
I noticed that the list of object types isn’t complete.
For example, if I want to read a Compact Data object (DLMS_OBJECT_TYPE_COMPACT_DATA, IC=62) or LTE Monitoring data (DLMS_OBJECT_TYPE_LTE_MONITORING, IC=151), these object types aren’t mapped in _GXObjectFactory.py.