Hi,
i’m having a SDM630 Modbus electric meter…a famous one and i guess some in the openhab community will work with it. Up to now i used a Python script that does the work and RESTs in the values to openhab.
I guess MODBUS binding does the same job way better. But i have no clue about the configuration, could not find any site/threat where this has been discussed.
Can someone give me some hits/advices/configs how i can bring in this SDM630. Thanks a lot! Norbert
Thanks Rich, i know the binding man page but this does not help if you see all these settings and things you can do wrong in terms of variants you can play. my hope is that someone has a successful installation running…and can tell me the settings required to make this a less painful transition from python script to modbus binding… Cheers, Norbert
I’m not sure if this is still of interest, but I found this thread while looking for a ready-to-use solution some weeks ago. Now I have a working setup, which I’d like to share:
.things file:
Bridge modbus:serial:sdm630_basis [port="/dev/ttyUSB0", id=1, baud=9600, stopBits="1.0", parity="none", dataBits=8, encoding="rtu"]
{
Bridge poller BasisWerte [start=0, length=36, type="input", refresh=5000] {
Thing data sdm_L1_volt [readStart="0", readValueType="float32" ]
Thing data sdm_L2_volt [readStart="2", readValueType="float32" ]
Thing data sdm_L3_volt [readStart="4", readValueType="float32" ]
Thing data sdm_L1_amp [readStart="6", readValueType="float32" ]
Thing data sdm_L2_amp [readStart="8", readValueType="float32" ]
Thing data sdm_L3_amp [readStart="10", readValueType="float32" ]
Thing data sdm_L1_power [readStart="12", readValueType="float32" ]
Thing data sdm_L2_power [readStart="14", readValueType="float32" ]
Thing data sdm_L3_power [readStart="16", readValueType="float32" ]
Thing data sdm_L1_va [readStart="18", readValueType="float32" ]
Thing data sdm_L2_va [readStart="20", readValueType="float32" ]
Thing data sdm_L3_va [readStart="22", readValueType="float32" ]
Thing data sdm_L1_var [readStart="24", readValueType="float32" ]
Thing data sdm_L2_var [readStart="26", readValueType="float32" ]
Thing data sdm_L3_var [readStart="28", readValueType="float32" ]
Thing data sdm_L1_powerfactor [readStart="30", readValueType="float32" ]
Thing data sdm_L2_powerfactor [readStart="32", readValueType="float32" ]
Thing data sdm_L3_powerfactor [readStart="34", readValueType="float32" ]
}
}
Bridge modbus:serial:sdm630_frequenz [port="/dev/ttyUSB0", id=1, baud=9600, stopBits="1.0", parity="none", dataBits=8, encoding="rtu"]
{
Bridge poller Frequenz [start=70, length=2, type="input", refresh=5000] {
Thing data sdm_frequency [readStart="70", readValueType="float32" ]
}
}
Bridge modbus:serial:sdm630_SystemPower [port="/dev/ttyUSB0", id=1, baud=9600, stopBits="1.0", parity="none", dataBits=8, encoding="rtu"]
{
Bridge poller SystemPower [start=52, length=2, type="input", refresh=5000] {
Thing data sdm_systemPower [readStart="52", readValueType="float32" ]
}
}
Bridge modbus:serial:sdm630_kWh [port="/dev/ttyUSB0", id=1, baud=9600, stopBits="1.0", parity="none", dataBits=8, encoding="rtu"]
{
Bridge poller kWh [start=342, length=22, type="input", refresh=5000] {
Thing data sdm_kwh_Totalkwh [readStart="342", readValueType="float32" ]
Thing data sdm_kwh_Totalkvarh [readStart="344", readValueType="float32" ]
Thing data sdm_kwh_L1_import_kWh [readStart="346", readValueType="float32" ]
Thing data sdm_kwh_L2_import_kWh [readStart="348", readValueType="float32" ]
Thing data sdm_kwh_L3_import_kWh [readStart="350", readValueType="float32" ]
Thing data sdm_kwh_L1_export_kWh [readStart="352", readValueType="float32" ]
Thing data sdm_kwh_L2_export_kWh [readStart="354", readValueType="float32" ]
Thing data sdm_kwh_L3_export_kWh [readStart="356", readValueType="float32" ]
Thing data sdm_kwh_L1_total_kWh [readStart="358", readValueType="float32" ]
Thing data sdm_kwh_L2_total_kWh [readStart="360", readValueType="float32" ]
Thing data sdm_kwh_L3_total_kWh [readStart="362", readValueType="float32" ]
}
}
.items file:
Group gModbus "Modbus Geräte"
Group gStromverbrauch "Stromverbrauch"
Group gElektrischeLeistung "elektr. Leistung"
Group gPhaseL1
Group gPhaseL2
Group gPhaseL3
Number SDM_L1_Spannung "Spannung L1 [%.2f V]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L1_volt:number"}
Number SDM_L2_Spannung "Spannung L2 [%.2f V]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L2_volt:number"}
Number SDM_L3_Spannung "Spannung L3 [%.2f V]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L3_volt:number"}
Number SDM_L1_Strom "Strom L1 [%.2f A]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L1_amp:number"}
Number SDM_L2_Strom "Strom L2 [%.2f A]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L2_amp:number"}
Number SDM_L3_Strom "Strom L3 [%.2f A]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L3_amp:number"}
Number SDM_L1_Leistung "Leistung L1 [%.2f W]" <energy> (gModbus, gPhaseL1, gElektrischeLeistung) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L1_power:number"}
Number SDM_L2_Leistung "Leistung L2 [%.2f W]" <energy> (gModbus, gPhaseL2, gElektrischeLeistung) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L2_power:number"}
Number SDM_L3_Leistung "Leistung L3 [%.2f W]" <energy> (gModbus, gPhaseL3, gElektrischeLeistung) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L3_power:number"}
Number SDM_L1_Scheinleistung "Scheinleistung L1 [%.2f VA]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L1_va:number"}
Number SDM_L2_Scheinleistung "Scheinleistung L2 [%.2f VA]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L2_va:number"}
Number SDM_L3_Scheinleistung "Scheinleistung L3 [%.2f VA]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L3_va:number"}
Number SDM_L1_Blindleistung "Blindleistung L1 [%.2f VAr]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L1_var:number"}
Number SDM_L2_Blindleistung "Blindleistung L2 [%.2f VAr]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L2_var:number"}
Number SDM_L3_Blindleistung "Blindleistung L3 [%.2f VAr]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L3_var:number"}
Number SDM_L1_Leistungsfaktor "Leistungsfaktor L1 [%.2f]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L1_powerfactor:number"}
Number SDM_L2_Leistungsfaktor "Leistungsfaktor L2 [%.2f]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L2_powerfactor:number"}
Number SDM_L3_Leistungsfaktor "Leistungsfaktor L3 [%.2f]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_basis:BasisWerte:sdm_L3_powerfactor:number"}
Number SDM_SystemPower "SystemPower [%.2f W]" <energy> (gModbus, gElektrischeLeistung, gElektrizitaet) {channel="modbus:data:sdm630_SystemPower:SystemPower:sdm_systemPower:number"}
Number SDM_Frequenz "Frequenz [%.2f Hz]" <energy> (gModbus, gElektrizitaet) {channel="modbus:data:sdm630_frequenz:Frequenz:sdm_frequency:number"}
Number SDM_kwh_Totalkwh "Gesamt Verbrauch kWh [%.2f kWh]" <energy> (gModbus, gStromverbrauch, gElektrizitaet) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_Totalkwh:number"}
Number SDM_kwh_Totalkvarh "Gesamt kVArh [%.2f kVArh]" <energy> (gModbus) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_Totalkvarh:number"}
Number SDM_kwh_L1_import_kWh "L1 Import [%.2f kWh]" <energy> (gModbus, gPhaseL1, gStromverbrauch) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L1_import_kWh:number"}
Number SDM_kwh_L2_import_kWh "L2 Import [%.2f kWh]" <energy> (gModbus, gPhaseL2, gStromverbrauch) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L2_import_kWh:number"}
Number SDM_kwh_L3_import_kWh "L3 Import [%.2f kWh]" <energy> (gModbus, gPhaseL3, gStromverbrauch) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L3_import_kWh:number"}
Number SDM_kwh_L1_export_kWh "L1 Export [%.2f kWh]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L1_export_kWh:number"}
Number SDM_kwh_L2_export_kWh "L2 Export [%.2f kWh]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L2_export:number"}
Number SDM_kwh_L3_export_kWh "L3 Export [%.2f kWh]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L2_export:number"}
Number SDM_kwh_L1_total_kWh "L1 Gesamt [%.2f kWh]" <energy> (gModbus, gPhaseL1) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L1_total_kWh:number"}
Number SDM_kwh_L2_total_kWh "L2 Gesamt [%.2f kWh]" <energy> (gModbus, gPhaseL2) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L2_total_kWh:number"}
Number SDM_kwh_L3_total_kWh "L3 Gesamt [%.2f kWh]" <energy> (gModbus, gPhaseL3) {channel="modbus:data:sdm630_kWh:kWh:sdm_kwh_L3_total_kWh:number"}
I also use the modus binding to communicate to my SDM630 V2 and it really works great. The modbus binding really saves a lot of work.
Currently I am struggling with using a feature of this meter, which is resetting the maximum demand values and the reset-able energy values.
The issue is: the related holding register is 461457, so a value within the 16-bit address range, which is getting more and more popular in recent devices.
From the binding documentation I understand that only an address range from 40001 to 49999 is supported. Recent devices would need support for the 16 bit address range, so from 400001 to 465536.
Is anybody aware of plans to adjust the really excellent modbus binding accordingly?
Not true. Try it.
The binding is quite simplistic here, and will use whatever register address you give as the 16-bit protocol bytes content.
But that won’t fit in 16 bits, the max is 65535.
Same as 40001 to 49999 convention, the 4xxxx is completely notional and not used in the actual protocol.
Meaning for use with our binding, you discard it altogether.
Use 61457
4 is not part of the address. 4 defines the data access, “4” for holding register.
Please also see
https://en.wikipedia.org/wiki/Modbus
... holding register numbers span from 400001 to 465536....
Modern Modbus devices use the address range beyond 9999 quite extensively. My example is not an exception. And for those devices the modbus binding as it is currently does not work. At least that’s my experience. Unless I miss something.
here my example in .things trying to access holding register 461457:
Bridge poller reset1 [ start=61456, length=2, refresh=1000, type=“holding” ] {
Thing data Reset00 [ readStart=“61456”, readValueType=“uint16”, writeStart=“61456”, writeValueType=“uint16”, writeType=“holding” ]
}
leads to this result:
2021-08-19 08:10:47.378 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Reset0’ received command 3
2021-08-19 08:10:47.400 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Reset0’ predicted to become 3
2021-08-19 08:10:47.403 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Reset0’ changed from 0 to 3
==> /var/log/openhab/openhab.log <==
2021-08-19 08:10:48.916 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0003), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID d3416d75-9456-408a-a9ee-17ed00dc8b87]
2021-08-19 08:10:50.460 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0003), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID d3416d75-9456-408a-a9ee-17ed00dc8b87]
2021-08-19 08:10:52.003 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0003), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Aborting. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID d3416d75-9456-408a-a9ee-17ed00dc8b87]
==> /var/log/openhab/events.log <==
2021-08-19 08:10:52.006 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:data:myserial01:reset1:Reset00’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0003), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null
2021-08-19 08:10:52.070 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:data:myserial01:reset1:Reset00’ changed from OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0003), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null to ONLINE
2021-08-19 08:10:52.073 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘Reset0’ changed from 3 to 0
The write did not work; nothing to do with address length. Does the device allow you to read from same register, does that actually work?
This useful doc
http://support.innon.com/PowerMeters/SDM630-MOD-MID/Manual/SDM630-Modbus_Protocol.pdf
does not mention anything about ‘Write single holding register’ FC06 being supported at all, I suspect that may be your problem.
Try using ‘Write multiple’ FC16, even for your one-register task.
There’s a comment
Holding registers are used to store and display instrument configuration settings. All holding registers not listed in the table below should be considered as reserved for manufacturer use and no attempt should be made to modify their values
and your 61456 is not mentioned in that table,but of course this is probably not a v2 meter doc.
It’s maybe worth pointing out that doc uses register ‘numbers’, e.g. 40001 is protocol address 0000. To use a register from that doc would need -1 for use in our Modbus binding.
dear rossko57, thank you very much for your support, appreciate it very much.
Unfortunately I still could not get it fully working.
Writing and reading holding registers works. This was already the before.
This hier below works fine. I can read and write without any errors. (holding register 40003)
Bridge poller holding1 [ start=2, length=2, refresh=1000, type=“holding” ] {
Thing data DemandPeriod00 [ readStart=“2”, readValueType=“float32”, writeStart=“2”, writeValueType=“float32”, writeType=“holding” ]
The issue is with the register to reset max demand value and resetable energy values.
Is should work similar, but it doesn’t. Reading works, but writing is not possible without any errors.
Writing the password to 40025 and getting the unlock confirmation in 40015 also works.
And I have got now three different versions of the Modus interface for this device. V1.6 from the web shop where I purchased the device, V1.7 from the webpage of Eastron Europe and the version I got from you above.
The issue is with the reset register (461457 uint16 according to V1.6 and V1.7) respectively 40217 float32 according to version from above).
For thouse holding registers reading works, but writing throws an error.
Writing to 461457 generates:
2021-08-20 13:13:48.730 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘Reset0’ received command 0
2021-08-20 13:13:48.741 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘Reset0’ predicted to become 0
==> /var/log/openhab/openhab.log <==
2021-08-20 13:13:50.274 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID 0df75b8a-51af-48ca-949a-c837b21fd83f]
2021-08-20 13:13:51.834 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID 0df75b8a-51af-48ca-949a-c837b21fd83f]
2021-08-20 13:13:53.377 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]). Aborting. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException Error reading response (EOF) [operation ID 0df75b8a-51af-48ca-949a-c837b21fd83f]
==> /var/log/openhab/events.log <==
2021-08-20 13:13:53.382 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:data:myserial01:reset1:Reset00’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null
2021-08-20 13:13:53.681 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:data:myserial01:reset1:Reset00’ changed from OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=61456, registers=ModbusRegisterArray(0000), maxTries=3, getFunctionCode()=WRITE_SINGLE_REGISTER]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message=‘I/O exception: IOException Error reading response (EOF)’, cause2=null to ONLINE
Writing to 40217 generates:
==> /var/log/openhab/openhab.log <==
2021-08-20 13:15:32.509 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=216, registers=ModbusRegisterArray(00000000), maxTries=3, getFunctionCode()=WRITE_MULTIPLE_REGISTERS]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 [operation ID 344f6275-7417-4c6d-9701-737a5d7f8ea0]
2021-08-20 13:15:32.589 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 2 out of 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=216, registers=ModbusRegisterArray(00000000), maxTries=3, getFunctionCode()=WRITE_MULTIPLE_REGISTERS]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 [operation ID 344f6275-7417-4c6d-9701-737a5d7f8ea0]
2021-08-20 13:15:32.652 [ERROR] [rt.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=216, registers=ModbusRegisterArray(00000000), maxTries=3, getFunctionCode()=WRITE_MULTIPLE_REGISTERS]). Aborting. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 [operation ID 344f6275-7417-4c6d-9701-737a5d7f8ea0]
==> /var/log/openhab/events.log <==
2021-08-20 13:15:32.399 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘i_reset2’ received command 0.0
2021-08-20 13:15:32.408 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘i_reset2’ predicted to become 0.0
2021-08-20 13:15:32.657 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:data:myserial01:p_reset2:t_reset02’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=216, registers=ModbusRegisterArray(00000000), maxTries=3, getFunctionCode()=WRITE_MULTIPLE_REGISTERS]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 ', cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 ', cause2=null
2021-08-20 13:15:33.477 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘modbus:data:myserial01:p_reset2:t_reset02’ changed from OFFLINE (COMMUNICATION_ERROR): Error (ModbusSlaveIOExceptionImpl) with write. Request: ModbusWriteRegisterRequestBlueprint [slaveId=1, reference=216, registers=ModbusRegisterArray(00000000), maxTries=3, getFunctionCode()=WRITE_MULTIPLE_REGISTERS]. Description: ModbusSlaveIOException(cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 ', cause2=null). Message: Modbus IO Error with cause=ModbusIOException, EOF=false, message='I/O exception: IOException CRC Error in received frame. 0 bytes of payload () with invalid CRC of 01 90 ', cause2=null to ONLINE
Any ideas?
Yes, same as before
Note that -
will by default use FC16 since it has to be multiple (16-bit) registers.
will by default use FC06 since you have specified a single register.
Does your device support FC06?
Note further that a lot of devices we’ve come across that use 32-bit registers will insist that you always write pairs anyway.
You’ll find it much easier to experiment if you use a third party Modbus test tool like Radzio, instead of editing Things. openHAB is not a good test system, it assumes that you know what is wanted before you start.
Now it works. (finally I got it.)
Forcing the binding to use FC16 ( writeMultipleEvenWithSingleRegisterOrCoil=true) was the key.
Thank you very much for your great support and your patience.
For future reference, writing a single 16-bit register works okay, no need to write a pair? (with FC16)
correct!
This here works:
Bridge poller reset1 [ start=61456, length=1, refresh=1000, type=“holding” ] {
Thing data Reset00 [ readStart=“61456”, readValueType=“uint16”, writeStart=“61456”, writeValueType=“uint16”, writeMultipleEvenWithSingleRegisterOrCoil=true, writeType=“holding” ]
}
Hi, just a novice question maybe … does a binding / device like this support ‘backfill’ of data…
maybe that is automatically taken care of … but …
what i mean … lets assume that you switch off your openhab server for a while … so you miss some data from some period of time (lets say few hours or days) — would that dat be backfilled into your persistent storage after you switch on the openhab server again ? or do you miss some data in that case ?
So with backfill i mean that the missing pieces of data are collected in a later stage from the device ? Pretty basic requirement i guess if you want solid reporting etc
thx koen
No.
Quite rightly, the server will not make up imaginary data to fill “gaps”.
That’s fine; the data is normally full of gaps because we only read/store it from time to time. For Modbus data, you might poll it once a second. So there will always be at least one-second gaps.
In reality, you would probably persist the data only once a minute at most. Or perhaps less often, hourly say.
The question you ought to be asking is how do we deal with gaps, because they are inevitable even in normal operation. In most cases, charts etc., features will generally simply assume the last good reading remains valid until the next reading.
I don’t know of any Modbus meters that keep any historic data that can be interrogated over Modbus.
There are certainly no built in features in openHAB to make use of anything like that, although you can script pretty much anything you want.
You might also worry about what happens if the meter itself is disabled for a period.
thanks, so it will depend on the device itself (which seems logical) … not sure about these modbus meters … i think for example shelly 3em meters store data on the device itself so maybe one can get it out off there in a later stage for certain periods to fill your gaps… for example my enphase micro invertors send / sync their data with the backoffice … either every 15 minutes or they backfille when for example your bridge was down for a while …
ps - i do not mean making up data – just getting the actual data for certain slot in later stage
You’re probably worrying at the wrong thing here. What problem do you anticipate having from “gaps”? As said, historic data is always “gappy”.
If yesterdays kWh reading was 125 and today’s is 130, the consumption was 5kWh whether or not you have a reading in-between of 127.5kWh
Note that openHAB is designed to be a full-time system; there aren’t a great deal of facilities to allow for being turned off for days at a time.
Sure, with gaps i do not mean the period between regular readings… i was just wondering how this works out … maybe with some more hands-on i can better define my use case and limitations when these situations occur… but it starts with the device bein capable of caching / storing data and allowing for it to be retrieved later on … reg koen
being a novice i am pretty sure i ‘worry’ about the wrong things at this stage… lol
This type of meters register the energy, so you will get kWh which might increase during the time the openhab is off.
Maybe you could get the difference between the status of the kWh counter before the openhab switched off and after it started and calculatethe difference. However openhab runs quite stable.
I have 3 similar single phase meters (I think they are model Eastron SDM120) and read them out via Modbus. They are all daisy chained with my ventilation unit and works well. I prefer those meters since they can accept 40A load and can even have MID approval for few euros extra
hi thx, for now i will try out the shell 3em first and maybe some modbus devices later on thx