golles / ha-kamstrup_403

Custom component that integrates the Kamstrup 403 heating system into Home Assistant. This component does also support a few other heating systems
MIT License
70 stars 10 forks source link

Request to enable using HA serial sensors #97

Closed MEOoms closed 11 months ago

MEOoms commented 1 year ago

Did you read the instructions?

The request

It would be great is there was an option to connect to a Home Assistant serial sensor, so that the serial data can be transmitted over wifi by a remote EspHome device. This can easily be done in EspHome using a streamserver on an esp32 with https://github.com/oxan/esphome-stream-server. This way, it is no longer necessary to have a complete HA instance running on a Pi close to the Kamstrup device.

Additional information

none

golles commented 1 year ago

Since version 2.5.0 you no longer need to connect the meter directly to the machine running HA. You can, for example, expose the serial connection over a socket, see about URL handlers: https://pyserial.readthedocs.io/en/latest/url_handlers.html#urls

MEOoms commented 1 year ago

Didn't know that, thanks. I run Hassio in a VM in windows. Can't figure out how to add pyserial there or in windows itself. I guess the HA forum is the place to ask this. Would you mind instructing me further (blush)....

golles commented 1 year ago

I wouldn't know, I use the cable :-)

You won't need to install pyserial, that library is being used in this component, I only shared that URL so you can see what kind of connections are supported. What you probably need, is a cable connected to a device (eg a Pi) and something like ser2net on that, to expose the serial connection over the network. For an ESPHome-based solution, the library you mentioned above might work, but you need to sort out how to set it up, the baudrate is 1200

MEOoms commented 1 year ago

Great! Though a newby, I will have no problem getting Esphome working, I have done that succesfully some times now. But Linux is still so strange to me, a windows adept. If I understand you correctly, in the configuration of the Kamstrup component in HA, instead of entering /dev/serial/by-id as the serial port, I can also enter eg socket://192.168.0.221:1234

Thanks so much for your help, HVC stadswarmte GJ prices over the prijsplafond are insane...

golles commented 1 year ago

Exactly You might want to get in touch with the maker of this issue, https://github.com/golles/ha-kamstrup_403/issues/95 According to the Diagnostics he uses a socket connection

JohNan commented 1 year ago

Out of curiosity, @MEOoms what sensor are you using to the esp? I'm currently running a RPi4 and socat to make a usb sensor available as a socket. But I would like to to have a more lightweight device instead.

Connecting through the socket works flawless. Just make sure to set the bandwidth to 1200 or else it won't work.

Here's the command and arguments to socat. You can ommit the -d flag to make the logs less noisy

socat -d -d -d -d tcp-listen:4001,reuseaddr,fork file:/dev/ttyUSB0,nonblock,b1200,raw,echo=0
MEOoms commented 1 year ago

@JohNan I just ordered this: https://www.ebay.nl/itm/354315601962 IR Schreib Lesekopf Stromzähler TTL Volkszähler / Smart Meter (Optokopf) It should work with esp32 and esp8266 and Esphome. I am trying to avoid linux/socat, as I have little experience with it and a dedicated RPi is overkill for such a small task in my view.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

MEOoms commented 1 year ago

Got everything installed. The remote Esphome serial server is running, the Kamstrup responds

17:22:34 [D] [uart_debug:114] >>> 80:3F:10:1B:F9:00:3C:00:44:00:63:00:71:03:E9:03:EC:1A:AA:0D
17:22:34 [D] [uart_debug:114] <<< 80:02:12:F0:00:02:00:00:42:00:60:03:C0:03:C8:1A:00:0D

The kamstrup integration however keeps the energy sensors as unavailable. HA integration Debug Logging in HA shows no errors. Is the response from the Kamstrup valid? It is a Kamstrup 602. Maybe I have the server uart wrong: 8 bits, 1 stopbit, no parity, 1200 baud?

MEOoms commented 1 year ago

Onlt when I disconnect the serial server I get this error in the Kamstrup log, suggesting that the integration normally receives the data ok, but does not transfer it to the entities. : Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.kamstrup_403 Source: helpers/update_coordinator.py:229 Integration: Kamstrup 403 (documentation, issues) First occurred: 18:22:39 (2 occurrences) Last logged: 19:22:41

Error fetching kamstrup_403 data:

MEOoms commented 1 year ago

No, debug log shows Rx is unsuccesful. Dont't get why.

023-07-22 22:31:33.182 DEBUG (MainThread) [custom_components.kamstrup_403] Start update 2023-07-22 22:31:33.182 DEBUG (MainThread) [custom_components.kamstrup_403] Get values for [60, 68, 99, 113, 1001, 1004] 2023-07-22 22:31:36.460 DEBUG (MainThread) [custom_components.kamstrup_403.pykamstrup] Rx Timeout 2023-07-22 22:31:36.460 DEBUG (MainThread) [custom_components.kamstrup_403] Finished update, 4 out of 0 readings failed 2023-07-22 22:31:36.460 DEBUG (MainThread) [custom_components.kamstrup_403] Finished fetching kamstrup_403 data in 3.279 seconds (success: True)

golles commented 1 year ago

No data is coming back from the meter, can you configure a longer timeout and see what happens?

MEOoms commented 1 year ago

The EspHome serial servers debug log shows:

17:22:34 | [D] | [uart_debug:114] | >>> 80:3F:10:1B:F9:00:3C:00:44:00:63:00:71:03:E9:03:EC:1A:AA:0D 17:22:34 | [D] | [uart_debug:114] | <<< 80:02:12:F0:00:02:00:00:42:00:60:03:C0:03:C8:1A:00:0D So my Kamstrup 602 is responding with 80:02:12:F0:00:02:00:00:42:00:60:03:C0:03:C8:1A:00:0D hex bytes within a second and sends this to the serial socket. Don;t know if this response is valid? I will try and set the timeout to 10 sec.

MEOoms commented 1 year ago

set to 5, this is max

MEOoms commented 1 year ago

No change: 2023-07-23 00:06:34.322 DEBUG (MainThread) [custom_components.kamstrup_403] Start update 2023-07-23 00:06:34.322 DEBUG (MainThread) [custom_components.kamstrup_403] Get values for [60, 68, 99, 113, 1001, 1004] 2023-07-23 00:06:39.680 DEBUG (MainThread) [custom_components.kamstrup_403.pykamstrup] Rx Timeout 2023-07-23 00:06:39.681 DEBUG (MainThread) [custom_components.kamstrup_403] Finished update, 4 out of 0 readings failed 2023-07-23 00:06:39.681 DEBUG (MainThread) [custom_components.kamstrup_403] Finished fetching kamstrup_403 data in 5.358 seconds (success: True)

I dont get the 4 out of 0 readings failed and succes: true Strangely, the Kamstrup meter keeps sending exactly the same response over and over:

<<< 80:02:12:F0:00:02:00:00:42:00:60:03:C0:03:C8:1A:00:0D

golles commented 1 year ago

I dont get the 4 out of 0 readings failed

This is wrong, see #100

and succes: true

I didn't want to raise any exceptions if there is something wrong instead log an error, which should also be fixed by the above PR

golles commented 1 year ago

To get some more logging (I'm still experimenting if I want to add this in), you could replace lines 45-57 in kamstrup.py with:

    def _debug(self, msg, byte_array: bytearray):
        """Log bytes to the logger"""
        _LOGGER.debug("%s %s", msg, byte_array)

    def _write(self, data: tuple[int]):
        """Write directly to the meter"""
        bytearray_data = bytearray(data)
        self._debug("Write", bytearray_data)
        self.ser.write(bytearray_data)

    def _read(self) -> int | None:
        """Read directly from the meter"""
        data = self.ser.read(1)
        if len(data) == 0:
            _LOGGER.debug("Rx Timeout")
            return None
        bytearray_data = bytearray(data)
        self._debug("Read", bytearray_data[0])
        return bytearray_data[0]
MEOoms commented 1 year ago

Thanks! I'll try.

github-actions[bot] commented 11 months ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions[bot] commented 11 months ago

This issue was closed because it has been stalled for 5 days with no activity.