Hello!
I have the same environment as described here: https://www.gurux.fi/forum/16596 but there no solution to the problem.
My meter natively supports MQTT protocol and I want to communicate directly using DLMS Director without using Gurux Bridge software. But when I try to do so the only messages that come to my topic are:
{
"id": 28,
"sender": "f06d16cd-e86c-48fb-8592-aad2955cc4da"
}
and then without receiving a response, the following message arrives
{
"id": 29,
"sender": "f06d16cd-e86c-48fb-8592-aad2955cc4da",
"type": 3
}
I would like to clarify a few questions:
1. Is it possible to communicate using DLMS Director software directly with meter using MQTT protocol without Bridge?
2. If so, what do I need to do?
3. Where can I find all the message types that you use for MQTT protocol to simulate Gurux Bridge responses on the meter side?
Regards,
Vladislav Savenia
Hi Vladislav, MQTT is not…
Hi Vladislav,
MQTT is not defined by DLMS standards. This means that the MQTT data structure can be anything.
Can you share the structure of the message so I can check if it's possible to add support for your meter?
BR,
Mikko
Hi Mikko, Thanks to Gurux…
Hi Mikko,
Thanks to Gurux.Broker, I managed to add support for all types of json messages that Gurux GXDLMSDirector sends/receives by viewing all incoming and outgoing traffic, now my device responds via mqtt without an Gurux.Bridge, so the previous questions are no longer relevant.
But after successful authorization, when trying to update the list of objects, Gurux GXDLMSDirector freezes after processing a certain message (when reading fields stored in profiles, when I disable them in the meter everything is fine), while when I try to close the program, the Gurux GXDLMSDirector starts working again: processes the incoming response, sends a new request and freezes again. Having done this trick several times, it is possible to completely update the list of objects, but I would like to know the possible reason for this behavior in order to avoid this.
I will try to share the screen recording later because in log everything seems fine.
15:49:14 --- Reading scalers and units end. ---
3:49:14 PM Reading object 1.0.99.1.0.255, interface ProfileGeneric
00 01 00 01 16 66 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 03 00
3:49:14 PM Get profile generic columns...
00 01 00 01 16 66 00 0D C0 01 C1 00 07 01 00 63 01 00 FF 03 00
--------THEN WE STUCK HERE UNTIL "CLOSE THE PROGRAM" TRICK--------
15:49:14 03:49:14.949 Received 00 01 16 66 00 01 00 60 C4 01 C1 00 01 05 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 01 1D 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 02 1D 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 03 1D 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 04 1D 00 FF 0F 02 12 00 00
3:49:46 PM
Have you had a similar experience?
Regards,
Vladislav