OSError: Int or String expected

[asprickmann]

Hi, I would love to use your code to read data from my logarex power meter but receive the following error. Can you help here?

Thanks in advance.

Andreas

pi@raspberrypi:~/2rs485/py-power-meter-monitor/py_power_meter_monitor $ poetry run py-power-meter-monitor --config-file /home/pi/2rs485/py-power-meter-monitor/etc/logarex-config.toml
DEBUG:asyncio:Using selector: EpollSelector
DEBUG:py_power_meter_monitor.commands:Opened serial connection /dev/ttyUSB1 with 9600 baud.
ERROR:mqtt:ASError.."localhost".."1883".."60".."".."0".."3".."None"..
Traceback (most recent call last):
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/asyncio_mqtt/client.py", line 198, in connect
    await loop.run_in_executor(
  File "/usr/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/paho/mqtt/client.py", line 914, in connect
    return self.reconnect()
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/paho/mqtt/client.py", line 1044, in reconnect
    sock = self._create_socket_connection()
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/paho/mqtt/client.py", line 3685, in _create_socket_connection
    return socket.create_connection(addr, timeout=self._connect_timeout, source_address=source)
  File "/usr/lib/python3.9/socket.py", line 822, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/lib/python3.9/socket.py", line 953, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
OSError: Int or String expected

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/typer/main.py", line 214, in __call__
    return get_command(self)(*args, **kwargs)
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/typer/main.py", line 532, in wrapper
    return callback(**use_params)  # type: ignore
  File "/home/pi/2rs485/py-power-meter-monitor/py_power_meter_monitor/cli.py", line 31, in run
    asyncio.run(
  File "/usr/lib/python3.9/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/home/pi/2rs485/py-power-meter-monitor/py_power_meter_monitor/commands/monitor_serial.py", line 45, in run_monitor_serial
    async with asyncio_mqtt.Client(
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/asyncio_mqtt/client.py", line 538, in __aenter__
    await self.connect()
  File "/home/pi/.cache/pypoetry/virtualenvs/py-power-meter-monitor-y57a_RBs-py3.9/lib/python3.9/site-packages/asyncio_mqtt/client.py", line 209, in connect
    raise MqttError(str(error))
asyncio_mqtt.error.MqttError: Int or String expected

[weltenwort]

hey @asprickmann :wave:

This looks like a network config value does not have the right type :thinking: Could you double-check that the hostname is a string and the port is a number? Alternatively, if you provide the config file you're using here I could take a look too.

[asprickmann]

Many thanks for your fast reply. The logarex config file beginning looks like shown below. BTW: I had to remove the parity parameter in serial_port section as it ran into a parsing error.

[logging]
level = 10 # error level (see built-in python logging levels)

[mqtt]
enabled = true
configuration_topic_template = "homeassistant/sensor/{entity_id}/config"
state_topic_template = "homeassistant/sensor/{entity_id}/state"
....

[mqtt.broker]
hostname = "192.168.178.23"
port = 1883

[mqtt.device]
id = "power-meter-0"
name = "Power Meter 0"
manufacturer = "Logarex"
model = "Unknown Model"

[serial_port]
port_url = "/dev/ttyUSB1"
baud_rate = 9600
byte_size = 8

[obis]

[[obis.data_sets]]
id = [1, 0, 96, 1, 0, 255]
name = "Meter Id"
value_type = "string"

[weltenwort]

I can't see anything wrong with the file. Maybe I'm not converting the port correctly? I ran into type conversion problems with the port argument for the socket module functions before.

Since mqtt.broker.port is the default port, could you try removing it from the file?

[asprickmann]

That was it! Many thanks. It is starting without errors if I delete the port in the config file or add quotation marks to the port value.

Unfortunately I do not get any values from the serial connection but assume it is an issue on my end. The debug log looks good, right?: DEBUG:asyncio:Using selector: EpollSelector DEBUG:py_power_meter_monitor.commands:Opened serial connection /dev/ttyUSB1 with 9600 baud. DEBUG:py_power_meter_monitor.workers:IEC 62056 state machine in state InitialState() DEBUG:py_power_meter_monitor.workers:IEC 62056 state machine evaluating effect SendMessageEffect(message=RequestMessage(timestamp=0, device_address='')) DEBUG:py_power_meter_monitor.workers:IEC 62056 state machine evaluating effect AwaitMessageEffect(message_type=<class 'py_power_meter_monitor.iec_62056_protocol.iec_62056_21_messages.IdentificationMessage'>) DEBUG:py_power_meter_monitor.iec_62056_protocol:Draining the read buffer up to b'/' DEBUG:py_power_meter_monitor.iec_62056_protocol:Gave up on draining the read buffer DEBUG:py_power_meter_monitor.iec_62056_protocol:Reading up to b'\r\n'

[weltenwort]

Glad you got one step farther :+1:

From the log it seems it's waiting in vain for a response from the power meter. Here are some potential problems that come to mind:

• Are you connecting to the power meter via wire or an optical head? For me the IR LED of the Logarex power meter was broken. I've heard it's a common problem with certain Logarex models that the IR LED ages too quickly. You could try to check if you can see the LED flashing using a mobile phone camera, which can usually see the IR frequencies. If the IR LED is broken or just disabled by the manufacturer, you might be able to get your grid provider to provide access to wired RS-485 ports, which is what I used.
• The baud rate and other serial settings might not match you device's expectations. Back in the days when I had a Logarex power meter it didn't implement the speed negotiation of IEC 62056-21 correctly, but always sent statically at 9600 baud. I had to try out various settings with stty and manually watch the byte-stream until I found settings using which it made sense. Thankfully the protocol is mostly ASCII, so one can tell valid from invalid messages by sight (using echo, cat and xxd).
• Some devices need to be put into the advanced "info" mode using the menu before they start transmitting messages. You can usually get the PIN to activate that menu item from your grid provider.
• Some devices need to be addressed with the correct "device address" in the sign-on message. No idea where one would get that address from. It might be printed on the label? :shrug:

Sorry that I can only offer speculations. Since these devices often only implement very specific parts of the IEC 62056-21 standard a lot of trial and error is involved. But I'd be happy to try to provide more input if you want to share your progress.

[asprickmann]

Many thanks for all your support. So great and highly appreciated! :-) I have the same issue, that I connected via IR before which out of a sudden stopped working. I also believe that the iR LED in the meter is broken. By lucky circumstances I had an electrician here to work on other stuff and saw that he opened up the meter. He was so nice, connecting a wire for me to the rs485 connection points.

• So the device is connected with a wire. As I did not receive anything as shown yesterday I checked the wire and changed the cable as I just saw at the bottom of my USB to serial device, that there were tiny marks indicating the right orientation. Now I am already receiving back this line: DEBUG:py_power_meter_monitor.workers:IEC 62056 state machine in state IdentifiedState(manufacturer_id='LOG', baud_rate_id='5', identification=' LK13BE803039')
• It looks like the connection parameters work well. Just to be sure, I played around with the parity and length but the current configuration was the only working one
• I already have the meter in "info" mode as I did before for the IR connection
• Not sure, if we need to send the device address, as the identification worked already. What do you think?

In the documentation of the meter, I found this sequence, which shows an ACK50 before sending data. Do we need to send it and is this implemented?

/LOG5LK13BE803049

050 1-0:96.1.0*255(001LOG0064800017) 1-0:1.8.0*255(000000.4392*kWh) 1-0:1.8.1*255(000000.0000*kWh) 1-0:1.8.2*255(000000.4392*kWh) 1-0:2.8.0*255(000000.8322*kWh) 1-0:16.7.0*255(000000*W) 1-0:32.7.0*255(000.0*V) 1-0:52.7.0*255(000.0*V) 1-0:72.7.0*255(229.9*V) 1-0:31.7.0*255(000.00*A) 1-0:51.7.0*255(000.00*A) 1-0:71.7.0*255(000.03*A) 1-0:81.7.1*255(000*deg) 1-0:81.7.2*255(000*deg) 1-0:81.7.4*255(000*deg) 1-0:81.7.15*255(000*deg) 1-0:81.7.26*255(000*deg) 1-0:14.7.0*255(49.9*Hz) 1-0:1.8.0*96(00000.0*kWh) 1-0:1.8.0*97(00000.0*kWh) 1-0:1.8.0*98(00000.0*kWh) 1-0:1.8.0*99(00000.0*kWh) 1-0:1.8.0*100(00000.4*kWh) 1-0:0.2.0*255(ver.03,EF8C,20170504) 1-0:96.90.2*255(0C69) 1-0:97.97.0*255(00000000) ! Best regards, Andreas Am Mi., 28. Dez. 2022 um 01:18 Uhr schrieb Felix Stürmer < ***@***.***>: > Glad you got one step farther 👍 > > From the log it seems it's waiting in vain for a response from the power > meter. Here are some potential problems that come to mind: > > - Are you connecting to the power meter via wire or an optical head? > For me the IR LED of the Logarex power meter was broken. I've heard it's a > common problem with certain Logarex models that the IR LED ages too > quickly. You could try to check if you can see the LED flashing using a > mobile phone camera, which can usually see the IR frequencies. If the IR > LED is broken or just disabled by the manufacturer, you might be able to > get your grid provider to provide access to wired RS-485 ports, which is > what I used. > - The baud rate and other serial settings might not match you device's > expectations. Back in the days when I had a Logarex power meter it didn't > implement the speed negotiation of IEC 62056-21 correctly, but always sent > statically on 9600 baud. I had to try out various settings with stty > and manually watch the byte-stream until I found settings using which it > made sense. Thankfully the protocol is mostly ASCII, so one can tell valid > from invalid messages by sight (using echo, cat and xxd). > - Some devices need to be put into the advanced "info" mode using the > menu before they start transmitting messages. You can usually get the PIN > to activate that menu item from your grid provider. > - Some devices need to be addressed with the correct "device address" > in the sign-on message. No idea where one would get that address from. It > might be printed on the label? 🤷 > > Sorry that I can only offer speculations. Since these devices often only > implement very specific parts of the IEC 62056-21 standard a lot of trial > and error is involved. But I'd be happy to try to provide more input if you > want to share your progress. > > — > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[weltenwort]

Great that you have a wired RS-485 connection :+1: much more reliable

You're making progress :tada: The IdentifiedState log line indicates that you received a response to your initial sign-on, so no device address seems to be necessary. Now the state machine should send the ACK message (implemented in https://github.com/weltenwort/py-power-meter-monitor/blob/f1cfd37cd08e849fa43767ebb74d1174faf1df85/py_power_meter_monitor/iec_62056_protocol/mode_c_state_machine.py#L110-L115), to which the power meter should respond with the STX frame containing all the OBIS data sets:

Can you show the full debug log?

[weltenwort]

One more thought: Maybe the device is too sensitive to timing. More specifically, maybe it's too slow to process our ACK message. You could try adjusting the response_delay setting in the [serial_port] section. The default is 0.3 (seconds), which might be too fast. Try setting it to 0.5 or even higher. The spec allows up to 1.5.

[asprickmann]

Thanks a lot again. It is working now and I already receive all the data in FHEM MQTT Server!!!

Now I just need to do two further steps:

1. Find out, how to extract the data from the FHEM MQTT server to implement a further logic in FHEM
2. Find out how to send some data to Volkszaehler for a better logging.

If you already did something in that direction, it would be great if you could share some insights.

Many thanks again for all your help.

Am Do., 29. Dez. 2022 um 01:05 Uhr schrieb Felix Stürmer < @.***>:

One more thought: Maybe the device is too sensitive to timing. More specifically, maybe it's too slow to process our ACK message. You could try adjusting the response_delay setting in the [serial_port] section. The default is 0.3 (seconds), which might be too fast. Try setting it to 0.5 or even higher. The spec allows up to 1.5.

— Reply to this email directly, view it on GitHub https://github.com/weltenwort/py-power-meter-monitor/issues/211#issuecomment-1366990480, or unsubscribe https://github.com/notifications/unsubscribe-auth/A46WMTNADLO4T636GD62FZLWPTIWJANCNFSM6AAAAAATJ6HQCI . You are receiving this because you were mentioned.Message ID: @.***>

[weltenwort]

Glad to hear it! What was the solution?

The MQTT messages are designed to work with the Home Assistant MQTT Discovery such that the power meter shows up as a device with sensors for the various measurements. The device_classes and state_classes are chosen such that the sensors work with the Home Assistant long-term statistics and the built-in energy dashboard.

I don't have any experience with FHEM or Volkszähler, sorry. You can adjust the topics that the messages are sent to in the config. Each OBIS data set configured in the config file is turned into an entity named after the name property of the data set. Each state topic contains the name of the entity. The messages sent to the state topics are just { 'timestamp': number, 'value': number | string } pairs. Without more context knowledge I'm not sure if that is any use to you, though.

[asprickmann]

I increased the response_delay setting to 0.7. As you assumed, this was the issue. Meanwhile I was also able to read the values in FHEM and send them to Volkszaehler.

Many thanks again for your great help.

Am Do., 29. Dez. 2022 um 13:29 Uhr schrieb Felix Stürmer < @.***>:

Glad to hear it! What was the solution?

The MQTT messages are designed to work with the Home Assistant MQTT Discovery https://www.home-assistant.io/integrations/mqtt#mqtt-discovery such that the power meter shows up as a device with sensors for the various measurements. The device_classes and state_classes are chosen such that the sensors work with the Home Assistant long-term statistics and the built-in energy dashboard.

I don't have any experience with FHEM or Volkszähler, sorry. You can adjust the topics that the messages are sent to in the config. Each OBIS data set configured in the config file is turned into an entity named after the name property of the data set. Each state topic contains the name of the entity. The messages sent to the state topics are just { 'timestamp': number, 'value': number | string } pairs. Without more context knowledge I'm not sure if that is any use to you, though.

— Reply to this email directly, view it on GitHub https://github.com/weltenwort/py-power-meter-monitor/issues/211#issuecomment-1367286932, or unsubscribe https://github.com/notifications/unsubscribe-auth/A46WMTIAIY2MML3SORV33L3WPV74BANCNFSM6AAAAAATJ6HQCI . You are receiving this because you were mentioned.Message ID: @.***>

[weltenwort]

That's awesome, thanks for sharing.