Hi,
I have some problems reading specific SAGEMCOM meters.
My Android app can read meters with a Bluetooth probe and with a USB serial probe.
BT probe readings are implemented with a third part library that works fine, and I can read all meters I tried (even these SAGEMCOM I am talking about).
On the other hand, USB probe readings are implemented using GURUX Android Serial library. The problem here is that there are some SAGEMCOM that when I tried to read Profile Generic OBIS "1.0.99.1.0.255" which is hourly readings.
The problem here is that the log of sent/received packages with BT and USB probe are the same, but when it comes to request the OBIS "1.0.99.1.0.255" afte the conenction, with the USB probe it doesn't respond and at some point it launches a release request to finish the conversation.
The USB probe works well as it works with other sagemcom and other manufacturers.
Is it possible that is some configuration of the probe or the client that is different? I tried different configs, but none of them worked (even with the BT probe does).
I wanna remark that I can read this same meter with the BT probe but not with the USB probe, so I don't think it's a firmware problem. I think it's more of a probe config problem, but I need your opinion here.
I attach you the log here:
USB log
# Connection
TX: 7EA0080221039386C17E
RX: 7EA01F030221737342818012050180060180070400000001080400000001533B7E
TX: 7EA0450221031043CAE6E6006036A1090607608574050801018A0207808B0760857405080201AC0A80083030303031393139BE10040E01000000065F1F0400001E1DFFFF0F267E
RX: 7EA010030221301058E6E700D801013C437E
# Request manufacturer
TX: 7EA01A02210332CDD7E6E600C001C100010000600104FF020065D27E
RX: 7EA02003022152D5CCE6E700C401C100090D534147303232363235333939327ACA7E
# Getting value scale units
TX: 7EA01A02210354FDD1E6E600C001C100030100011D00FF0300FEE37E
RX: 7EA01703022174EC6CE6E700C401C10002020F00161E61D47E
# Request "1.0.99.1.0.255"
TX: 7EA04D022103765396E6E600C001C100070100630100FF0201010204020412000809060000010000FF0F02120000090C07E9041BFF00000000800080090C07E90501FF000000008000800100C0997E
# No response, so it's sent again automatically
TX: 7EA04D022103765396E6E600C001C100070100630100FF0201010204020412000809060000010000FF0F02120000090C07E9041BFF00000000800080090C07E90501FF000000008000800100C0997E
After all these msg with the USB probe I receive the package, which seems the problem :
RX: 7EA0080302218172127E
Meanwhile with the BT probe I receive the first package of the requested OBIS
RX: 7EA88A03022196C9CBE6E700C402C100000000010081E001610208090C07E9041B0700000000800080118206000000060600000000060000000006000000000600000006000000040208090C07E9041B070100000080008011820600000006060000000006000000000600000000060000000006000000040208090C07E9041B070200000080008015E37E
...
and so on
As I said, is it possible that could be some configuration that I have different on the client or probe that makes this difference?
Do you need any other info a part of these tat could help find the problem here?
Thank you so much in advance!
PD: At the beginning I couldnt even read the OBIS "0.0.98.1.1.255" with the same problem, then I added these skips to the GXDatetime objects before the request and it worked for the OBIS "0.0.98.1.1.255" but still does not work for the OBIS "1.0.99.1.0.255".
Set<DateTimeSkips> skips = new HashSet<>();
skips.add(DateTimeSkips.DAY_OF_WEEK);
skips.add(DateTimeSkips.DEVITATION);
gxDate.setSkip(skips);
I don't know what else check so I am out of ideas for these... x'(
Hi, BT or USB connection…
Hi,
BT or USB connection doesn't affect to this problem.
I believe that the problem is with the date-time format. Some meters require that the date-time be in a specific format, which can be achieved with DateTimeSkips. It always depends on the meter manufacturer and how well date-time support is implemented.
Try to read your meter with GXDLMSDirector. In that way you can get the correct date-time settings that you need to use to read your meter. You can modify the settings in the Advanced tab.
BR,
Mikko