search

UtilitechAS / amsreader-firmware

ESP8266 and ESP32 compatible firmware to read, interpret and publish data to MQTT from smart electrical meters, both DLMS and DSMR is supported
Other
386 stars 73 forks source link

Kamstrup Omnipower - unknown data received #862

Closed mtjoernelund closed 4 days ago

mtjoernelund commented 5 days ago

Describe your problem I have had AMS reader flashed on generic ESP32 Wroom working very reliably for a long time. But after an update I suddenly get no data. HAN simply turns red and I get the error “HAN: Unknown data received, check meter config“. I’ve checked the config and it should be correct. According to previous issues raised, a reset might be needed. I have requested and the grid company confirmed that the interface had been reset.

The GUI is a little unclear on the config settings I think, but I assume that the following is correct for the encryption: Top text field = gpk60 - encryption_key Bottom text field = gpk61 - authentication_key

Not sure where to look from here?

Hardware information:

Relevant firmware information:

ArnieO commented 5 days ago

What was the update?

Yes, that is correct for the encryption.

Our devices have an LED connected to the incoming data line, giving a visual indication on incoming data from the meter.

Try this:

If incoming data is confirmed, please post your config screen.

mtjoernelund commented 5 days ago

I had a failed power supply, so when I had to swap that I thought I might as well update AMS Reader version. I was previously on ver. 2.1.x (cannot remeber). But did a clean install of 2.3.8. That is the only update that has been done.

I am running the software flashed on a generic ESP32 wroom development card. So no flashing LED.

I was trying to run telnet debug, but I cannot find the system option to enable telnet debugging?

ArnieO commented 5 days ago

I am running the software flashed on a generic ESP32 wroom development card. So no flashing LED.

I understand, and just wanted to give inform you on why that is a useful feature (you could add it to your device). You should also be able to see the data burst with a multimeter.

You enable telnet debug on the bottom of the config screen: image

mtjoernelund commented 5 days ago

Strange. I do not have the debug option in config screen: IMG_0157

Should I try downgrading to a previous version?

ArnieO commented 5 days ago

OK, sorry - it is possible that telnet debug isn't shown on devices with manual setup, probably by precaution, as we will not know how the hardware looks. I'm sure @gskjold can clarify that when he's available.

But I see something you should change: You have "LED disable" set to GPIO0, which does not make sense. You surely do not use "LED disable", and GPIO 0 is used for setting the ESP32 into flashing mode (in combination with RESET/EN).

So try this:

The rest looks OK.

Have you tried to measure the input to GPIO16 when connected to the meter? You should be able to detect a data burst each 10 seconds.

mtjoernelund commented 5 days ago

Ok. Tried to downgrade. On version 2.2.28 now I can access telnet for debugging. I get the following:

(W) Unknown data received (V) payload: (V) FF FE A1 F1 90 C0 37 20 58 CD 82 A0 FF 6A 36 14 (V) 03 60 63 08 DF 1F 40 45 81 2A 96 6D 14 09 6E F1 (V) 01 26 CD A8 F9 D4 3F FC 54 E1 9B C3 18 C1 C0 DB (V) 2B 18 FC AE 35 35 65 5E 09 4F B4 CD A7 E3 87 43 (V) D5 DD AC B1 43 86 6F F8 2A 94 6D FC A4 3E 2A E3 (V) 72 04 EE B3 A2 4E 82 D1 50 48 7E 19 EF 90 6C 8E (V) 8E 53 A9 A4 24 28 3F C2 0D 0A 9C CA B8 A9 A5 A8 (V) F5 EE F2 27 E4 2B BF 4F 8A D5 88 7E 85 6F B8 A5 (V) 7D 75 2C 2C 02 E0 46 FF F5 2D E0 2F 5E F9 66 45 (V) 81 83 3E 4D 5D 5C 3D 3D BF 5F 88 06 47 AC B6 BF (V) 45 D9 45 9D 96 5D DA C1 F8 FA 44 83 A8 AE F3 94 (V) 62 0D DA 79 52 71 84 80 F1 8E 13 24 68 07 7F 19 (V) 04 FD 70 90 66 9E (W) Used 2569ms to read HAN port (true) (W) loop() used 2581ms (W) No HAN data received last 30s, single blink (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF FF FF FF (W) Used 1165ms to read HAN port (true) (W) No HAN data received last 30s, single blink (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF FF
(E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF (E) Ended up in default case while unwrapping...(tag E4) (W) Unknown data received (V) payload: (V) E4 32 6D 2B B4 D7 0B F5 4F B9 D2 4B F7 FF 54 62 (V) 04 01 BC B2 98 0D 51 88 6E C0 71 60 DE B3 7C EB (V) D6 03 8B 16 75 E3 D4 AB 10 2A 0E FF EE 48 8C 9A (V) 00 62 46 A2 C0 D6 AB 4F 1D 07 13 FD 89 F1 05 D1 (V) 02 95 B8 2A 25 61 6D 2A 80 71 81 B7 C7 C1 10 AE (V) 43 A0 58 BD 9B C1 FE 4E 64 F1 6C 87 BC 8B 0A 5F (V) 87 94 1D 53 F5 DD 49 0F 80 63 E9 22 88 B4 AC 82 (V) EF AA 94 3E 9C 77 58 BE F8 2C 35 40 3A 03 37 89 (V) BE 42 4A 82 BD 58 A1 DF FC 2C BD 87 74 46 2F F3 (V) 98 6B A9 04 94 FE 28 7B 28 35 FF B8 8D 8A FF 4A (V) CD 20 03 01 B1 9D 12 69 B0 35 DF 97 3A 10 8F FB (V) D7 5B BF DD 30 2D 61 2E F2 3E 8F 3F E2 (W) Used 2346ms to read HAN port (true) (W) loop() used 2360ms (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF FF FF FF FF (W) Used 1069ms to read HAN port (true) (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF (W) No HAN data received last 30s, single blink (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF 00 (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF FF FF (E) Ended up in default case while unwrapping...(tag FF) (W) Unknown data received (V) payload: (V) FF FF FF (E) Ended up in default case while unwrapping...(tag A0)

This just goes on…

I’ve also tried to change cables, to ensure that there is good connection between the ESP and the HAN interface.

I’ve not yet tried to measure input to the GPIO, but based on the above output it does seem that data is coming through, right?

ArnieO commented 5 days ago

Huh. Yes, there is something arriving there - but what you're receiving is more or less "rubbish", the two payloads you show there should have many similarities.

I believe this is a Danish frame/payload - for reference: https://github.com/UtilitechAS/amsreader-firmware/blob/main/frames/Kamstup-Encrypted.raw

A valid payload starts and ends with 7E, this is mine (but my payload in Norway is shorter than yours in Denmark).

(V) HDLC frame:
(V) 7E A0 E2 2B  21 13 23 9A  E6 E7 00 0F  00 00 00 00
(V) 0C 07 E8 0A  1E 03 11 20  00 FF 80 00  00 02 19 0A
(V) 0E 4B 61 6D  73 74 72 75  70 5F 56 30  30 30 31 09
(V) 06 01 01 00  00 05 FF 0A  10 35 37 30  36 35 36 37
(V) 32 37 37 36  35 36 36 37  32 09 06 01  01 60 01 01
(V) FF 0A 12 36  38 34 31 31  33 31 42 4E  32 34 33 31
(V) 30 31 30 34  30 09 06 01  01 01 07 00  FF 06 00 00
(V) 0E F1 09 06  01 01 02 07  00 FF 06 00  00 00 00 09
(V) 06 01 01 03  07 00 FF 06  00 00 00 00  09 06 01 01
(V) 04 07 00 FF  06 00 00 01  83 09 06 01  01 1F 07 00
(V) FF 06 00 00  00 6A 09 06  01 01 33 07  00 FF 06 00
(V) 00 03 E3 09  06 01 01 47  07 00 FF 06  00 00 02 59
(V) 09 06 01 01  20 07 00 FF  12 00 F2 09  06 01 01 34
(V) 07 00 FF 12  00 F0 09 06  01 01 48 07  00 FF 12 00
(V) F2 17 EC 7E

Have you always used GPIO16? Is this a development module, or a board you have developed yourself? If this is a module, do you have the schematic for it? Are you sure there is nothing else connected to GPIO16?

mtjoernelund commented 5 days ago

It is a development module ESP32 wroom 48 pin. I do not have the schematics. The weird thing here is that this is the same board I have had connected since version 2.1.x was the latest. Literally the only thing changed since it worked absolutely flawless is that I have replaced the power supply. I used to power the board at the 5v pin from a no-name 5v power supply that died. Now I power the board from the USB port. Other than that I have changed nothing other than installing 2.3.8 on the same board. Jumpers to the meter were the same until I replaced them this afternoon to rule out a faulty jumper giving a bad connection. I even tried rolling back to version 2.1.17. Same result.

Could it be a power issue? Maybe I need to replace the power supply?

mtjoernelund commented 5 days ago

Hmm…

Tried replacing the power supply with a brand name usb. Made a small difference. Now I get some data through, but it turns red again with the message : “HAN: Footer checksum error”. It still updates some of the information but not consistently.

ArnieO commented 4 days ago

I used to power the board at the 5v pin from a no-name 5v power supply that died. Now I power the board from the USB port.

This is probably your issue. The ESP pulls heavy current pulses while working on Wi-Fi, and in this application it does a lot of Wi-Fi communication. Without a strong power supply there is a significant risk that things starts getting messed up.

In our products we have a HUGE low-ESR supercapacitor on 3,3V to ensure the voltage remains stable. Your previous 5V power supply might have been able to ensure the power was sufficiently stable. If you have a BIG low-ESR (important!) capacitor you can solder in on the 3,3V you might be able to improve the situation. An electrolytic will probably not work (too high ESR = Equivalent Serial Resistance). A BIG tantalum might do the trick.

Good luck!