HAN green but no data?

[Cartoon-Dude]

Hello
The HAN is in green, that means it should receive the data?
But it seems there's nothing at all. Is there an option to see the raw data to check if something is indeed sent?
Thanks

[gskjold]

https://www.amsleser.no/blog/post/24-telnet-debug

[Cartoon-Dude]

Thank you
So it has data, even said it is valid, but apparently do nothing with it.
AMS.log

[gskjold]

L&G meter? What country?

[Cartoon-Dude]

No, it is a Iskra AM550, Switzerland
I saw it as compatible in the FAQ

[Cartoon-Dude]

Ok, so we can expect a response in a month or two with luck, else up to a year to find the correct person, if one ever would give some kind of documentation at all.

[ArnieO]

@Cartoon-Dude: As you can see, we can read the meter - but in your case the payload format is not standard, so we probably need to update the code.
Are you running a Pow-P1 from amsleser.no? We have to prioritize solving issues for our customers right now, thank you for your understanding.

[gskjold]

I know what this is now, they are using a different method of segmenting data. This have been reported earlier, but I have not taken the time to implement it

[Cartoon-Dude]

Do you accept donations? I would be happy to help this project having more meters supported.
For context: I bought a DSMR reader but didn't worked, asked the industrial services in june 2023 about what protocol was used, received a response last week saying it is instead DLMS. Luckily was able to flash it with your firmware.
Since it took 6 months to just know what protocol is used, it would take at least as long to have more details about the protocol.

[ArnieO]

Thank you for your generous offer to donate to our project. We primarily finance our work through the sale of our Smart Meter Readers, predominantly to customers in Europe. You can find more information on our Github page.

We've made the decision to publish our source code to ensure users have full control over their data. Our code is designed so that data is not transmitted unless users explicitly configure their device to do so, such as to an external MQTT broker. We believe consumption data is sensitive and should be fully controlled by the user.

Our aim is to make our devices compatible with all smart meters that adhere to the physical interface standards we support. These include M-bus on RJ12, M-bus on RJ45, P1 companion on RJ12, and our unique solution for the Kamstrup Omnipower expansion bay.

The next challenge lies in the payload format. Our firmware is flexible enough to handle payloads with OBIS codes we have already encountered, even if the number of parameters in the paylod differs from other smart meters. However, if we encounter a payload with a new OBIS parameter, we need to update the code, as it's not practical to implement all OBIS codes available in the standard.

Occasionally, we encounter additional issues with the way the payload is constructed, as with your meter. In these cases, we investigate and make the necessary adaptations for the next firmware patch. This process can take anywhere from a few days to a few weeks, depending on our other workload and priorities. In the meantime, @gskjold typically provides a test firmware to the affected user.

Since our funding comes from hardware sales, we prioritize customers who have purchased a device but are experiencing difficulties. We also prioritize regions with significant sales potential for our products.

The most effective way you can assist us is by promoting our products within your network, including friends, colleagues, family, and on social media. We don't spend money on advertising; our primary sales channel is satisfied customers. This approach has allowed us to grow from a small hobby project in 2021 to a business in a registered company since the end of last year, where @gskjold and myself lay down parts of our available time.

While we're still operating on a relatively small scale, we believe the potential for growth is huge. Our ambitious goal is to become a leading supplier of smart meter readers, and we aim to achieve this by prioritizing customer service and exceeding customer expectations!

[Cartoon-Dude]

@gskjold Another electricity company ordered the same meter with apparently the same implementation, and it this time is documented. Maybe it could help.

[ArnieO]

Merci bien!

That does not look too out-of-the ordinary, except the use of double counting: Heures Pleines et Heures Creuses:

I recognize this from France: The meters need two separate energy counters, as there is a "hardcoding" by a special signal wire that comes from the grid - that can for instance be used for connecting your water boiler (chaudière) so that it only heats water during the night, when the electricity price is significantly lower. It is in fact a quite clever system, once that infrastructure is in place! That same signal wire is (I assume) used for switching the counter in the Smart meter.

@gskjold : Could it just be that this meter uses OBIS codes we have not implemented yet, for these low/high tariff double counters?

@Cartoon-Dude : Est-ce que vous aussi est situé dans un région francophone, avec se système de comptage?

[Cartoon-Dude]

Oui, c'est exactement ça.
Tout les fournisseurs du pays ont deux tarifs, de jour et de nuit + weekend. Le signal de tarif est utilisé par le compteur ainsi que pour enclencher des appareils comme boiler, chauffage à accumulation, etc...

[ArnieO]

OK, je soupçonne donc que les "coupables" ici sont les quatre derniers codes OBIS.

OK, I then suspect that the "culprits" here are the two last four OBIS codes, that we have not needed to use before now, so as soon as @gskjold finds time...

[gskjold]

I will make the segmentation assembler work with this data format. Also, the resulting frame is same as a L&G meter we have previously added support for.

E6 E7 00 // LLC
0F 00 32 A0 3B // Flag & sequence
0C 07 E7 0C 14 03 15 19 1E 00 FF C4 00 // Timestamp 
02 13 // Object with 13 values
  01 13 // Array with 13 values (Metadata)
    02 04 12 00 28 09 06 00 06 19 09 00 FF 0F 02 12 00 00 // 25.9.0
    02 04 12 00 28 09 06 00 06 19 09 00 FF 0F 01 12 00 00 // 25.9.0
    02 04 12 00 03 09 06 01 01 01 07 00 FF 0F 02 12 00 00 // 1.7.0
    02 04 12 00 03 09 06 01 01 02 07 00 FF 0F 02 12 00 00 // 2.7.0
    02 04 12 00 03 09 06 01 01 01 08 00 FF 0F 02 12 00 00 // 1.8.0
    02 04 12 00 03 09 06 01 01 02 08 00 FF 0F 02 12 00 00 // 2.8.0
    02 04 12 00 03 09 06 01 01 03 08 00 FF 0F 02 12 00 00 // 3.8.0
    02 04 12 00 03 09 06 01 01 04 08 00 FF 0F 02 12 00 00 // 4.8.0
    02 04 12 00 03 09 06 01 01 01 08 01 FF 0F 02 12 00 00 // 1.8.1
    02 04 12 00 03 09 06 01 01 01 08 02 FF 0F 02 12 00 00 // 1.8.2
    02 04 12 00 03 09 06 01 01 02 08 01 FF 0F 02 12 00 00 // 2.8.0
    02 04 12 00 03 09 06 01 01 02 08 02 FF 0F 02 12 00 00 // 2.8.2
    02 04 12 00 03 09 06 01 01 03 08 01 FF 0F 02 12 00 00 // 3.8.0
    02 04 12 00 03 09 06 01 01 03 08 02 FF 0F 02 12 00 00 // 3.8.2
    02 04 12 00 03 09 06 01 01 04 08 01 FF 0F 02 12 00 00 // 4.8.1
    02 04 12 00 03 09 06 01 01 04 08 02 FF 0F 02 12 00 00 // 4.8.2
    02 04 12 00 03 09 06 01 00 1F 07 00 FF 0F 02 12 00 00 // 31.7.0
    02 04 12 00 03 09 06 01 00 33 07 00 FF 0F 02 12 00 00 // 51.7.0
    02 04 12 00 03 09 06 01 00 47 07 00 FF 0F 02 12 00 00 // 71.7.0
  // Actual values for above metadata:
  09 06 00 06 19 09 00 FF // 25.9.0
  06 00 00 02 1B // 1.7.0
  06 00 00 00 00 // 2.7.0
  06 00 53 50 BE // 1.8.0
  06 00 4C 7D 2E // 2.8.0
  06 00 06 BA 4C // 3.8.0
  06 00 01 36 18 // 4.8.0
  06 00 48 AB 95 // 1.8.1
  06 00 0A A5 29 // 1.8.2
  06 00 0D 12 9A // 2.8.1
  06 00 3F 6A 94 // 2.8.2
  06 00 02 B6 95 // 3.8.1
  06 00 04 03 B7 // 3.8.2
  06 00 00 BA AA // 4.8.1
  06 00 00 7B 6E // 4.8.2
  12 00 67 // 31.7.0
  12 00 14 // 51.7.0
  12 00 8F // 71.7.0

[ArnieO]

@gskjold / @Cartoon-Dude : Is this working as expected now?
See #785

[Cartoon-Dude]

Yes, it is ok for me since the version 2.3.2

[Jack-Harper]

You have all the sensors working? (Voltage, current, tariff a/b)

[Cartoon-Dude]

There's apparently no voltage data sent for my model, current is here, and low/high tariff combined in the interface