Feature Request: Set Fallback Values to Zero When No Data is Observed

[mister2d]

Description:
It would be helpful if taptap could set fallback values (like current and voltage) to 0.0 when no new data is observed. This ensures that downstream consumers, such as dashboards or MQTT brokers, don't display stale or misleading values when data stops flowing.

Use Case:
In systems like solar monitoring setups, sensor data naturally stops transmitting at night. Currently, stale "last-will" messages or old data can cause dashboards to display incorrect constant values until the next morning. By setting current and voltage to 0.0, users can avoid this issue.

Proposed Solution:

• Add a mechanism to detect when no new data has been observed over a configurable period (e.g., 1 minute).
• When this condition is detected, emit fallback values (0.0) for key fields like current and voltage.

Example Desired Output:
Here’s an example JSON output that taptap could emit when no data is observed:

{
  "current": 0.0,
  "voltage": 0.0,
  "rssi": 126,
  "temperature": 17.4
}

[litinoveweedle]

Hello,

I am in the process of writing taptap to MQTT bridge and I will be implementing exactly such a feature. Honestly I do not think, that this is something it has to be implemented in the taptap, as from the architecture point of view this is higher data manipulation function then the simple decoding of the tigo protocol.

Another data manipulation feature will be also translation table from the module serial to the friendly name through translation table. This table would also works as list of the modules to be able to detect any module missing or not reporting data. But again something which can easily live inside of the higher SW function. (Written in something more hackable like python :-) ).

[mister2d]

Thank you for the update and for working on adding MQTT support to taptap! That sounds like a great enhancement. That would simplify workflows like mine.

Currently, my setup looks like this:

taptap --> named pipe --> telegraf [named pipe input] --> telegraf [mqtt output]

In this workflow, taptap streams its JSON output to a named pipe, and Telegraf handles reading from the pipe and publishing the data to an MQTT topic.

Let me know if you’d like more details on my workflow, or if there’s anything I can test or contribute as MQTT support evolves. Thanks again for the great work!

PS - friendly name through translation would be welcome as well. It would make it basically feature complete from an observability standpoint (imo).

[litinoveweedle]

Just to be fair. I am not author of the TapTap, so I am also very thankfull to @willglynn for his work. I just want it to make it easier for me and others to use it inside out home automation. I will post more info about the MQTT bridge here, hopefully soon.

[willglynn]

I think it's do-able in taptap. Observer has a NodeTable and could synthesize a non-report event if it didn't hear from a given node after a particular reporting interval. Non-report events could reasonably be interpreted as the node being offline, as distinct from taptap or the gateway being offline.

[litinoveweedle]

Sure it is doable. But then you can only assume what modules you have really installed. Maybe some were added or removed, other could die etc. Tigo gateway has a complete list of provisioned list of modules serials. To be able to replicate the same functionality you would need to have a similar list as a configuration input. Otherwise it will be guesswork at least to some degree.

[willglynn]

Each gateway contains a node table, exhaustively enumerating all the modules with which it communicates. Observer captures this table, and it sees each gateway's slot counter, and it sees each report from each module received from each gateway. Using this information to generate no-report events requires no configuration and relies on no guesswork.

[mister2d]

Each gateway contains a node table, exhaustively enumerating all the modules with which it communicates. Observer captures this table, and it sees each gateway's slot counter, and it sees each report from each module received from each gateway. Using this information to generate no-report events requires no configuration and relies on no guesswork.

This is great to hear. It reassures my concern of the request being out of scope. taptap already has commands other than observe that extends beyond minimal decoding functionality.

I thought it would be a small feat to extend observe to handle the absence of new data, or create another command such as monitor to actively monitor and process the stream.

[litinoveweedle]

Ok, thank you for this information. I didn't know it - i.e. that taptap is able to get the node table from the gateway using only passive communication sniffing. If so then my comment was incorrect.

[willglynn]

@litinoveweedle The node table contains the 64-bit long addresses of the associated modules. This is enough to synthesize events from modules which aren't transmitting, which satisfies the ask here.

You're right that this information is incomplete. As far as I know, neither the gateway nor the modules themselves know:

• friendly names (A1, B2, etc.)
• the electrical layout (which modules are connected to which strings in which sequence) ‡
• the physical layout (which modules are up/right/down/left from which other modules)

This information isn't necessarily required, and I'd like taptap to work without it… but it is useful, and I'd like to support providing it via a config file or similar. It'd be nice if users could make events say {"name": "A2" instead of just providing IDs.

‡

I suspect that some information about the electrical layout is encoded in the PV configuration, but I also suspect this information is incomplete. Using my install as an example, I have two strings A1-A7 and B1-B7 which are paralleled into a single MPPT input. I think that my A string modules and B string modules each know they are in series together, and I think that all these modules know that their string is paralleled with the other string, but I do not think A2 knows it is in series after A1 and before A3. I haven't worked to extract this information because I think it would be better to support user-provided names for each ID.

[litinoveweedle]

I hacked my gateway and if I remember correctly it contains friendly names of modules, but doesn't have the layout (neither electrical nor physical). That information is only stored in the cloud as far as I know.

My goal is to get taptap into HomeAssistant for easy use. So I am working on the taptap MQTT bridge with the HA auto-discovery. All the other higher level informations like the layout can be then easily handled in the HA, so I am not going to implement those.