Cannot work registers

[daimonkor]

Please check parsing registers. I tried create the task at other repository too. Thanks for support. Please check my config. I used only 2 channels A and B.
litinoveweedle/taptap-mqtt#10

[litinoveweedle]

Hi @willglynn , this is once again not directly relevant for your repo.

You can close this issue, although I would be interested if you finished implementation of the messages which updates addresses (GW phys addr and nodes addr/barcodes), in the observe mode.

What I see in the code is that it shall be implemented in the way, that once enumeration messages are received and processed addresses are update in the Node and Gateway structs and shall be from that time outputted in the Power Event JSONs. But I never saw those! It could be, that this is because in my setup connection to TCP Modbus converter fails at least once per day and as persistent storage for addresses in not implemented..... So what is the status, did you ever get phys addr/barcodes in the observe mode???

[litinoveweedle]

ref #6 (comment)

[litinoveweedle]

Reading the protocol docs application layer Nodes long addresses are contained in the Packet Type 27 - Node table response, which shall by your statistical packet table were received ~800 times a day.

I was recently able to fix taptap to reconnect, therefore not loosing communication with Modbus TCP converter every few hours and now I am running it the observe mode, but still not seeing any addresses nor under the "gateway" neither in the "node" JSON key. So to me something seems not to be working as supposed.

@willglynn have you ever saw physical addresses/barcodes to be filed in the observe mode?

[litinoveweedle]

I am actually getting pretty sure, that the packet type 27 are not handled correctly at all.

When doing taptap in the peek-byte, I can see packets like:

FF 7E 07 92 01 0B 10 00 0E 00 27 02 00 0F .................
FF 7E 07 92 01 0B 10 00 0E 00 27 03 00 13 ................

but other taptap instance running at the same time in the peek-activity mode do NOT log any packets of the type:

NODE_TABLE_RESPONSE

So it seems there is a bug.

[litinoveweedle]

OK, the issue seems to be, that EVERY single NodeTableResponse message is failing to be read from bytes in the

pv/application/receiver.rs:

        let Ok(response) = NodeTableResponse::ref_from_bytes(response) else {
            self.counters.invalid_node_table_responses += 1;
            return;
        };

I put there debug message so see when the ref_from_bytes fails. And it fail always. For example here is one such message (I took liberty to replace some bytes in the address part with XX:

FF 7E 07 92 01 0B 10 00 0E 00 27 77
00 0F
     00 04
           04 C0 5B 40 00 XX XX XX 00 0F
           04 C0 5B 40 00 XX XX XX 00 10
           04 C0 5B 40 00 XX XX XX 00 11
           04 C0 5B 40 00 XX XX XX 00 12
F7 74 7E 08

Based on your protocol description that message seems legit. I know that I am probably annoying, but can I please get @willglynn some response? Did you ever get node table response parsing working?

[litinoveweedle]

The ref_from_bytes fails with Err: SizeError

[litinoveweedle]

OK, do not need your reply anymore, found the issue. It could never worked in live, also test for packet type 27 is not implemented. case closed.

[tbrasser]

Hey, I'm using an esphome reimplementation of taptap (https://github.com/N30dG/esphome-components), and have issues parsing frames. I'm suspecting tigo tap and/or optimizer firmware upgrade (corresponding maybe with cca 4.0.1-ct firmware)

Could this be related?

[litinoveweedle]

Could be. I am currently trying with one of the users to find the issue. It would help me to get remote access to the converter for testing. You can PM me here

[willglynn]

@tbrasser I'm on 3.8.0-ct and have not observed a format change. What are you seeing?

[litinoveweedle]

@willglynn I can confirm similar issue from the taptap fork, seems that Tigo in the latest firmware changed gateway transport protocol:

original Receive Request:
00 FF FF 7E 07 12 01 01 48 00 01 18 83 04 17 44 7E 08

new one:
00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 7B 00 01 7E 04 68 7E 08

see the packet type changed from the 01 48 to 00 42, similar for

original Receive Response:
FF 7E 07 92 01 01 49 00 FE 01 83 5A DE 07 00 0A 01 14 63 3A … 7E 08

new (empty) one:
FF 7E 07 92 01 00 43 8A 00 85 E6 85 CF 00 01 08 7B 00 0D 00 01 00 00 00 00 BC BA 7E 08

again frame type changed from 01 49 to 00 43

so there seems to be new implementation of how the packets from PV modules are transferred via Modbus in the newest FW.

You can check captured messages here

[tbrasser]

Grok says:

The provided capture contains a large number of RS-485 frames exchanged between the Tigo CCA and TAP, including repeated queries/responses, command strings like "Info", "Stat", and "GetVis", and data blocks that appear to contain optimizer metrics (e.g., floats for voltage/current/temperature encoded in IEEE 754 format, prefixed with IDs like AB 10).
This is sufficient to reverse-engineer and add support for the new protocol in TapTap and derivatives like the ESPHome TigoTap component, as it reveals patterns in frame structure, commands, and data payloads that differ from older firmware (e.g., potential new headers or checksums in responses). However, ideal updates would require additional captures during active solar production for full validation of dynamic data fields.

Key Observations from the Capture

• Frame Format: Frames are delimited by 7E (HDLC-style flag). Typical structure: 7E + address/control (e.g., 07 12 for CCA queries, 07 92 for TAP responses) + sequence/ID bytes + data + checksum + 7E. No obvious encryption; data is mostly readable.
• Repeated Patterns: Early frames show idle polling (e.g., CCA query 00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 73 00 01 66 AE 7E 08, TAP response with zeroed data like 00 00 00 00). This suggests no production data yet, but establishes baseline communication.
• Commands and Responses: Includes explicit ASCII commands (e.g., "^16Info\r@@04C05B8067EC\r" with serial number), short acknowledgments (e.g., 09 F1 9A), and longer data responses with optimizer info (e.g., blocks like AB 10 3E 63 7F 71 12 FE 44 B7 E5, likely ID + float values for V_in, V_out, I_out, temp).
• Changes from Old Protocol: Compared to pre-4.0 firmware (32-byte packets starting with AA, XOR checksum), new frames have extended headers (e.g., 85 E5 85 CE prefixes), variable lengths, and possibly CRC-16 instead of XOR. Float values align with expected solar metrics (e.g., 3E 63 ~22V if scaled), but IDs and status bytes may have shifted.
• Data Sufficiency: Covers discovery, status polling, and metric reporting for multiple optimizers (IDs like AB 10–17, 8A 14–17, etc., suggesting 16+ units). Missing: High-production data or error states, but enough for initial parsing logic.

[willglynn]

@tbrasser The AI summary doesn't make any sense to me but @litinoveweedle's capture does. There's a new gateway receive request/response exchange using at least message types 00 42/01 42/00 43.

Looking just at the request side, I wonder if 01 42 is some kind of acknowledgement:

00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 73 00 01 66 AE 7E 08
00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 73 00 01 66 AE 7E 08
…60 more times…
00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 73 00 01 66 AE 7E 08
00 FF FF 7E 07 12 01 01 42 00 00 CA 68 7E 08
00 FF FF 7E 07 12 01 01 42 00 00 CA 68 7E 08
00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 75 00 01 BF 78 7E 08
00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 7B 00 01 7E 04 68 7E 08
00 FF FF 7E 07 12 01 00 42 00 40 00 01 08 7B 00 01 7E 04 68 7E 08

I also don't see any response field which seems to correspond to the gateway's slot counter, and if that's no longer explicitly communicated, this would complicate assigning timestamps to reports.

[litinoveweedle]

For clarity: That capture is from one of the users of the taptap for HA, not mine. I am still on the v3 FW.

So the question is if we will be able to reverse engineer the new protocol.

We can always fallback to timestamp = now(). I would not consider this to be the biggest problem. In the worst case sometimes we would receive some older frames?