Siemens TD-3511 Smartmeter

[wolkenjaeger]

I am trying to implement a REST service for the Siemens TD3511 and it seems there are some issues with reading the respsonses by this lib.

First things first: TD-3511 documentation: https://wiki.volkszaehler.org/_media/hardware/channels/meters/power/siemens/amis_td-351x_bhbk.pdf Basically I use the information provided here: https://wiki.volkszaehler.org/hardware/channels/meters/power/edl-ehz/siemens_td3511 (German)

The hardware is working when using this script: https://pastebin.com/GjXAzPbv

I tested the same hardware with following smartmeter-obis config:

var options = {
    'protocol': "D0Protocol",
    'transport': "SerialRequestResponseTransport",
    'transportSerialPort': "/dev/ttyUSB0",
    'transportSerialBaudrate': 300,
    'transportSerialMessageTimeout': 30000,
    'protocolD0WakeupCharacters': null,
    'protocolD0DeviceAddress': '',
    'requestInterval': 1200,
    'obisNameLanguage': 'en',
    'obisFallbackMedium': 6,
    'debug': 2,
    'logger': 'console.log'
};

Which gave me following output: https://pastebin.com/UHjm3das

It looks like the lib does not recognize the answers of the TD-3511

[Apollon77]

From a log perspective the communication seems ok in general. Means start sequence is sended, smartmeter answers as expected, the ack with baudrate change is send (0x06060) as also shown on Volkszaehler page, and then baudrate is changed but then only crap comes in.

So the smartmeter OR the reader is not repecting the baudrate changeover.

YOur other script is setting the baudrate not to 19200, but to 9600 ... you could try to set option "protocolD0BaudrateChangeoverOverwrite = 9600" to see if this works better.

[wolkenjaeger]

That was it! Setting 9600bd was the solution. I know have a lot of content to parse except some OBIS code according the error messages: https://pastebin.com/KWGqABN5

[Apollon77]

Very strange. So I assume that your reading had or the OS or other timing things may prevent you from using 19200 baud ... Because the smartmeter should be able to do it.

For the error ... your smartmeter is returning invalid OBIS :-( There is no official definition fpr C.60.5.1 ... it should be C.60.5*1.

I see two options .... enhance parser to allow also a pint at the certain position and handle it as if it would be "previousMeasurement" meaning (you could try to adopt https://github.com/Apollon77/smartmeter-obis/blob/master/lib/ObisMeasurement.js#L27 and add the point to [*&] ... or better discard such errors that they are not logged ...

[wolkenjaeger]

Thanks for the quick help again. I really don't know why I have this 9600bd limitation. It's not a bad thing for my purpose. I will create anyway a service, which stores only the recent values and returns them to MQTT for further processing (statistics).

Last question: the labels for the different fields are all indicating "Heat", but it's electricity: is this a config setting or also something coming wrong from my smartmeter?

[Apollon77]

Remove the obisFallbackMedium :-) or set to 1 for electricity

[wolkenjaeger]

It just occured to me that the library seems not to ignore "wrong" OBIS code by itself because I never get to the point where the callback function is used... or do I use the err object ?

[Apollon77]

Your log shows that the callback function is used. In fact callback will be called for each error with "err" only and one last time at the end with no err with the data

[wolkenjaeger]

Okay, I understand now the principle (I guess). However, I still recieve a "ERROR CLOSING SERIALPORT" warning after each request, even with debug level 0. Do you have an idea, what this could be?

Following the debug level 2 output. I checked the source, but I cannot guess why the serial port is supposedly already closed. It will work for my MQTT client, but the "ERROR" is not random, but after every FINALIZATION.

Transport Reset!! Restart = false STORE DATA 1552937780031: Current Power Usage: 0.632 kW 1552937780031: Total Power Usage: 31205.472 kWh LEFT AFTER HANDLE-MESSAGE 3 CURRENT PROCESS STEP 10 IN ISPROCESSCOMPLETE: true RESUME READING SERIALPORT IN FINALIZE SET MESSAGE TIMEOUT TIMER: 60000 CURRENT PROCESS STEP 10 IN ISPROCESSCOMPLETE: true CLEAR MESSAGE TIMEOUT TIMER REMAINING DATA AFTER MESSAGE HANDLING: ( END FINALIZE ERROR CLOSING SERIALPORT SERIALPORT CLOSE SERIALPORT REMOVE LISTENERS CURRENT SIGNON MESSAGE COUNTER 1 OF 1 DELETE rest of data (0) because new Message start with a new Request Message SCHEDULE NEXT RUN IN 20000s