No luck, same error into the logs and no P1 meter found
Hmm. Don’t know why the change was not included. But I’ve updated the binding (02-03-2023-3). It should not have the this error anymore.
Fixed. Thank you so much for the quick turn around. awesome stuff!
Hi All,
Firstly, thanks for the cool hints and work, in particular @hilbrand !
Still, I’m struggling with my SageCom T-210 on the P1 port from an Austrian grid supplier (Graz).
I’m not managing to reach any state beyond “Unknown”.
I’m using a PI4 with openhabian and I know that my serial port is working as I receive some data on t
the port (checked with minicom).
I’ve also got the two keys from my supplier so the thing never goes online so I was wondering if perhaps someone can share some screenshots or data files showing the configuration?
Also, my cable is just over 3m long, could that be a problem?
Last but not least:
I use the Beta version of the DSMR binding, add the keys etc but when I then start the scan, it restarts the whole openhab and nothing gets added.
Any hints are much appreciated.
To configure my SageCom T-210 I added the following definition to
$OPENHAB_CONF/things/smartmeter.things:
Bridge dsmr:smartyBridge:0d83a50ffe [serialPort="/dev/ttyUSB0"] {
Things:
electricity_smarty_v1_0_austria electricityV5 "S210 - Stromz\u00e4hler" [channel=0, refresh=20]
}
With the additional encryption key it should look like this:
Bridge dsmr:smartyBridge:smartMeter "SmartMeter Bridge" [serialPort="/dev/ttyUSB0", decryptionKey="xxxxx", additionalKey="yyyyy", receivedTimeout=90] {
Things:
electricity_smarty_v1_0_austria dsmr0 "SmartMeter" [channel=0, refresh=10]
}
Maybe you have to switch decryptionKey and additionalKey - it’s sometimes not possible to determine which one is which 
Which version of openHAB are you running? Does the log contain some additional info when the restarts happen?
When using the Beta addon you need to make sure the serial bundle is installed (see topic description).
Theoretical it’s possible the data is corrupted due to cable issues (This seems the most common issue). In that case the binding can’t read the data. However when the corruption is minor it might be able to detect the meter sometimes during discovery scan, but not read the data (because the data is encrypted and has no error margin for corrupted data). Therefor it’s also interesting to find out why openHAB restarts.
No, doesn’t matter if I swap the keys, still the same issue.
The only real difference is that I use the GPOP serial port, so “/dev/ttyAMA0” instead of USB.
The port seems to receive data, as I explained above though.
The openHAB version is 3.4.4 and yes, the serial binding is installed, but I haven’t created a serial binding device or bridge. I guess that’s OK and not required?
Regarding the cable:
I’ve only used the Rx and Gnd wires, guess that’s OK as well?
As far as I know from my first tests, these two wires ar NOT ENOUGH because the SagemCom meter also needs a ready signal (HIGH on Data Request Pin) to send valid data regularly. That was the reason why I switched to a complete converter with USB - e.g. Amazon Link
BR
Sorry, yes the meter gets a +5V signal on pin 2 (basically just jumpered its +5V from pin 1 to pin 2).
It’s the sending data and if that jumper is removed, the data string stops.
However, I’ve the RX and GND input connected directly between the meter and the Pi and I now think the RX input needs some circuit (as also suggest by @sorlob - thanks again). Not sure if that’s purely for signal conditioning or if it’s actually inverting the signals.
Hello again,
Thank yo all for your help.
I’ve swapped the self-made cable using the GPIO serial interface to the USB one and it all came live instantly. I believe the reason why the GPIO interface didn’t work is because the signals need inverting and I’d no external circuit to do that.
Two very minor issues I’ve observed:
The version item (p1_version_output_) isn’t received.
These two channels seem to have unit ‘var’ and not ‘kvar’ (emeter_actual_reactive_delivery, emeter_actual_reactive_production).
Otherwise it’s super stable.