Skip to content

Issue with throttling and multiple devices #210

@Tweakie

Description

@Tweakie

What's the issue?

I have 2 Marstek Venus V3 batteries which are using the B2500 as meter source.
When one battery is running for a while and I power the second battery, it can not find the emulted Shelly meter.

Your setup

  • Installation method: Docker
  • Storage system: Venus 3.0 firmware V139
  • Power meter source: Homewizard energy meter polled via JSON_HTTP

Configuration

[GENERAL]
DEVICE_TYPE = shellypro3em
THROTTLE_INTERVAL = 1

[JSON_HTTP_1]
URL = http://192.168.66.112/api/v1/data
# Comma separated JSON paths - single path for 1-phase or three for 3-phase
JSON_PATHS = $.active_power_w
NETMASK=192.168.66.114

[JSON_HTTP_2]
URL = http://192.168.66.112/api/v1/data
# Comma separated JSON paths - single path for 1-phase or three for 3-phase
JSON_PATHS = $.active_power_w
NETMASK=192.168.66.115

Error messages or logs

Upper console shows the log of the B2500 application
Bottom console shows a tcpdump with a capture filter on port 1010
Image
Packets from the second battery (192.168.66.115) are arriving but are not seen by the application.

Some time later:
Image

Packets from second battery are seen and processed.

When I switch off the second battery:
Image
No packets from the second battery are seen with tcpdump, but the application is still seeing packets coming in and is responding.

Additional info

My hypotheses: due to the throttling mechanism, it takes around 1 second to handle a packet. A Marstek battery is sending 2 requests per second. After a few seconds of handling incoming requests, all threads of the worker queue are handling packets and are waiting to send a response. New incoming packets are getting queued in the Linux socket buffer. As new packets come in faster than they are handled, the number of packets in the Linux socket buffer increases. When I enable my second battery, the complete Linux socket buffer should be processed before the first packet of the second battery is handled.

A possible solution could be to drop a request from a battery if a request for that battery is already being handled. This will avoid the queueing in the Linux socket buffer.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions