Neue Versionen und Support zum Modbus-Modul

[abc2006]

Hi Stefan, erstmal vielen Dank für die Arbeit, die du dir gemacht hast, und genauso vielen Dank für die Umsetzung meiner/unserer Wünsche!
Ich habe die Dateien leider erst heute morgen bei mir einspielen können. Dabei sind mir folgende Punkte aufgefallen und Gedanken gekommen:

a) set .. active/inactive über die Kommandozeile funktioniert, evtl wäre es sinnvoll, dieses noch im dropdown hinzuzufügen.

b) Bei durchsicht des Logfiles habe ich den Eindruck, dass die während "set inactive" eingehenden Anfragen gespeichert werden und nach einem "set active" abgearbeitet werden:

Code Auswählen Erweitern

2020.11.01 10:40:38.897 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:39.963 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:39.963 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:39.965 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -27
2020.11.01 10:40:39.966 5: infini_modbus_logical: PackObj packed -27 with pack code f>1 to c1d80000
2020.11.01 10:40:39.966 5: infini_modbus_logical: PackObj padded / cut object to c1d80000
2020.11.01 10:40:39.966 5: infini_modbus_logical: PackObj full data string is c1d80000
2020.11.01 10:40:39.967 5: infini_modbus_logical: PackObj padded / cut data string to c1d80000
2020.11.01 10:40:39.967 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:39.968 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:41.016 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:41.017 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:41.025 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -27
2020.11.01 10:40:41.026 5: infini_modbus_logical: PackObj packed -27 with pack code f>1 to c1d80000
2020.11.01 10:40:41.026 5: infini_modbus_logical: PackObj padded / cut object to c1d80000
2020.11.01 10:40:41.027 5: infini_modbus_logical: PackObj full data string is c1d80000
2020.11.01 10:40:41.027 5: infini_modbus_logical: PackObj padded / cut data string to c1d80000
2020.11.01 10:40:41.027 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:41.028 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:42.072 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:42.073 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:42.075 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -27
2020.11.01 10:40:42.076 5: infini_modbus_logical: PackObj packed -27 with pack code f>1 to c1d80000
2020.11.01 10:40:42.076 5: infini_modbus_logical: PackObj padded / cut object to c1d80000
2020.11.01 10:40:42.077 5: infini_modbus_logical: PackObj full data string is c1d80000
2020.11.01 10:40:42.077 5: infini_modbus_logical: PackObj padded / cut data string to c1d80000
2020.11.01 10:40:42.078 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:42.079 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c1d80000, device infini_modbus_logical (RTU), pdu 0404c1d80000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:42.715 5: infini_modbus_logical: SetState called from Modbus::ControlSet with inactive sets state and STATE to inactive
2020.11.01 10:40:42.718 5: infini_modbus_logical: UnregAtIODev called from Modbus::SetLDInactive
2020.11.01 10:40:42.718 5: infini_modbus_logical: UnregAtIODev is removing infini_modbus_logical from registrations at infini_modbus_physical
2020.11.01 10:40:42.719 5: infini_modbus_logical: UnregAtIODev is removing locks at infini_modbus_physical
2020.11.01 10:40:42.719 5: infini_modbus_logical: UnregAtIODev is removing locks at infini_modbus
2020.11.01 10:40:42.778 5: sendSerialCommand argument ? _Line: 89
2020.11.01 10:40:42.778 5: sendSerialCommand argument fragezeichen _Line:91
2020.11.01 10:40:54.255 5: infini_modbus_logical: SetState called from Modbus::ControlSet with active sets state and STATE to active
2020.11.01 10:40:54.257 3: infini_modbus_logical: RegisterAtIODev called from Modbus::SetLDActive registers infini_modbus_logical at infini_modbus_physical with id 1, MODE slave, PROTOCOL RTU
2020.11.01 10:40:54.257 3: infini_modbus_logical: using infini_modbus_physical for communication
2020.11.01 10:40:54.259 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.260 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.261 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.261 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.262 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.262 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.262 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.263 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.263 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.266 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.266 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.267 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.268 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.268 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.268 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.269 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.269 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.270 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.272 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.273 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.274 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.274 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.274 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.275 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.275 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.275 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.276 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.278 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.279 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.280 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.280 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.281 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.282 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.285 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.285 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.286 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.287 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.288 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.289 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.291 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.291 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.292 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.293 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.293 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.293 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.294 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.294 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.295 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.297 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.298 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.299 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.299 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.300 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.301 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.304 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.304 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.305 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.306 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.307 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.307 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.310 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.310 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.311 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.312 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.312 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.312 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.313 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.313 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.314 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.316 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.317 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.318 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.318 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.318 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.319 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.319 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.319 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.320 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.323 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.323 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.324 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.324 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.325 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.326 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:54.354 5: sendSerialCommand argument ? _Line: 89
2020.11.01 10:40:54.355 5: sendSerialCommand argument fragezeichen _Line:91
2020.11.01 10:40:54.790 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:54.790 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:54.792 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 674
2020.11.01 10:40:54.792 5: infini_modbus_logical: PackObj packed 674 with pack code f>1 to 44288000
2020.11.01 10:40:54.792 5: infini_modbus_logical: PackObj padded / cut object to 44288000
2020.11.01 10:40:54.793 5: infini_modbus_logical: PackObj full data string is 44288000
2020.11.01 10:40:54.793 5: infini_modbus_logical: PackObj padded / cut data string to 44288000
2020.11.01 10:40:54.793 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:54.794 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 44288000, device infini_modbus_logical (RTU), pdu 040444288000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:55.847 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:55.848 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:55.850 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 685
2020.11.01 10:40:55.851 5: infini_modbus_logical: PackObj packed 685 with pack code f>1 to 442b4000
2020.11.01 10:40:55.852 5: infini_modbus_logical: PackObj padded / cut object to 442b4000
2020.11.01 10:40:55.852 5: infini_modbus_logical: PackObj full data string is 442b4000
2020.11.01 10:40:55.853 5: infini_modbus_logical: PackObj padded / cut data string to 442b4000
2020.11.01 10:40:55.853 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:55.854 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 442b4000, device infini_modbus_logical (RTU), pdu 0404442b4000, V 4.3.2 - 30.10.2020
2020.11.01 10:40:56.901 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 10:40:56.902 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 10:40:56.904 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value 691
2020.11.01 10:40:56.905 5: infini_modbus_logical: PackObj packed 691 with pack code f>1 to 442cc000
2020.11.01 10:40:56.906 5: infini_modbus_logical: PackObj padded / cut object to 442cc000
2020.11.01 10:40:56.906 5: infini_modbus_logical: PackObj full data string is 442cc000
2020.11.01 10:40:56.907 5: infini_modbus_logical: PackObj padded / cut data string to 442cc000
2020.11.01 10:40:56.907 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 10:40:56.909 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value 442cc000, device infini_modbus_logical (RTU), pdu 0404442cc000, V 4.3.2 - 30.10.2020
^C


• in meinem Fall ist es nicht notwendig, die Antworten nachzuholen
• Ich könnte mir vorstellen, dass das bei FHEM Probleme gibt, wenn die Abfragen alle gespeichert werden
• Ich könnte mir vorstellen, dass das bei FHEM Probleme gibt, wenn die Abfragen alle auf einen Schlag beantwortet werden
• Ich könnte mir vorstellen, dass das bei diversen Endgeräten Probleme gibt, wenn die Abfragen alle auf einen Schlag beantwortet werden
• In meinem Fall liefert es auch keinen Mehrwert, weil das abgefragte Reading max. 1x pro sekunde aktualisiert wird, d.h. alle zwischenzeitlichen Antworten senden den gleichen Wert

Ich werde das mal umbauen und über Nacht betreiben. Wenns dann weitere Probleme geben sollte, melde ich mich.

c)
Ich habe das logische Modul (ModbusAttr) auf set .. inactive gesetzt, und danach das noch vorhandene attr disable 0 gelöscht.
Das bewirkte, dass das Modul wieder auf aktiv sprang. Ist ja eigentlich kein Problem, kommt bestimmt auch selten vor. Fiel mir aber auf, ich weiss ja nicht, ob das Absicht oder ein Fehler ist.

Nochmal Danke
Grüße,
Stephan

[StefanStrobel]

Hallo Stephan,

a) set .. active/inactive über die Kommandozeile funktioniert, evtl wäre es sinnvoll, dieses noch im dropdown hinzuzufügen.

Stimmt. kommt in der nächsten Version

b) Bei durchsicht des Logfiles habe ich den Eindruck, dass die während "set inactive" eingehenden Anfragen gespeichert werden und nach einem "set active" abgearbeitet werden:

Das macht der Master. Wenn er seinen Slave nicht erreichen kann, bleiben die Anfragen in seiner Queue. Über queueTimeout kann man das aber beeinflussen.
Ein Slave im Zustand disabled oder inactive sollte eingehende Anfragen abweisen. Eine Queue gibt es für eingegangene Anfragen nicht.

• Ich könnte mir vorstellen, dass das bei FHEM Probleme gibt, wenn die Abfragen alle gespeichert werden

Auch das kann man über dropQueueDoubles und queueMax auf Seite des Masters einstellen.

• Ich könnte mir vorstellen, dass das bei FHEM Probleme gibt, wenn die Abfragen alle auf einen Schlag beantwortet werden

Genau. Ein Slave kann daher nur eine Anfrage bearbeiten und ein Master schickt immer nur dann eine neue Anfrage, wenn die alte beantwortet wurde oder in einen Timeout gelaufen ist.

• Ich könnte mir vorstellen, dass das bei diversen Endgeräten Probleme gibt, wenn die Abfragen alle auf einen Schlag beantwortet werden

Für den Master gibt es hier detaillierte Timing-Einstellungen um Probleme zu vermeiden, falls ein Slave nicht schnell genug ist.

c)
Ich habe das logische Modul (ModbusAttr) auf set .. inactive gesetzt, und danach das noch vorhandene attr disable 0 gelöscht.
Das bewirkte, dass das Modul wieder auf aktiv sprang. Ist ja eigentlich kein Problem, kommt bestimmt auch selten vor. Fiel mir aber auf, ich weiss ja nicht, ob das Absicht oder ein Fehler ist.

Das ist Absicht. Das Modul merkt sich nicht, welcher Zustand vor einem disable bestand. Inactive ist ja auch kein eigenes Attribut, das gespeichert bleibt, sondern das state-Reading. Disable überschreibt das. Entsprechend kann das Modul nach einem entfernen des disable-Attributs nur zu active wechseln.

Gruss
   Stefan

[abc2006]

Hallo Stefan,
danke für deine Erklärungen. Ich habe dazu noch ein paar Verständnisfragen:

Das macht der Master. Wenn er seinen Slave nicht erreichen kann, bleiben die Anfragen in seiner Queue. Über queueTimeout kann man das aber beeinflussen.

Verstehe ich richtig, dass der Master der ist, der abfragt? Also habe ich doch mit

Code Auswählen Erweitern

defmod infini_modbus_logical ModbusAttr 1 slave
keinen Master, sondern einen slave?
Das würde ja bedeuten, der Master ist mein Wechselrichter. Den kann ich aber leider nicht beeinflussen...
Ich glaube aber auch nicht, dass der WR eine queue hat.. entweder kommt eine Antwort - oder halt nicht...

Ein Slave im Zustand disabled oder inactive sollte eingehende Anfragen abweisen. Eine Queue gibt es für eingegangene Anfragen nicht.

Wie erkläre ich mir dann, dass nach einem set active viele Antworten innerhalb weniger ms gesendet werden, in Abständen die deutlich geringer sind als die Abfragen normalerweise kommen? (siehe Beispiel unten)

Ein Slave im Zustand disabled oder inactive sollte eingehende Anfragen abweisen. Eine Queue gibt es für eingegangene Anfragen nicht.
Auch das kann man über dropQueueDoubles und queueMax auf Seite des Masters einstellen.

Ich glaube, ich missverstehe deine definition von "Master"...

Genau. Ein Slave kann daher nur eine Anfrage bearbeiten und ein Master schickt immer nur dann eine neue Anfrage, wenn die alte beantwortet wurde oder in einen Timeout gelaufen ist.

Das ist offensichtlich leider nicht so:
Beispiel:
log-auszug direkt nach einem set .. active:

Code Auswählen Erweitern

response: id 1, fc 4 i52, len 2, value 41200000
2020.11.01 12:11:58.724 5: infini_modbus_physical: DropFrame - drop 0104003400023005
2020.11.01 12:11:59.351 5: infini_modbus_logical: SetState called from Modbus::ControlSet with inactive sets state and STATE to inactive
2020.11.01 12:11:59.354 5: infini_modbus_logical: UnregAtIODev called from Modbus::SetLDInactive
2020.11.01 12:11:59.354 5: infini_modbus_logical: UnregAtIODev is removing infini_modbus_logical from registrations at infini_modbus_physical
2020.11.01 12:11:59.355 5: infini_modbus_logical: UnregAtIODev is removing locks at infini_modbus_physical
2020.11.01 12:11:59.412 5: sendSerialCommand argument ? _Line: 89
2020.11.01 12:11:59.412 5: sendSerialCommand argument fragezeichen _Line:91
2020.11.01 12:12:07.574 5: infini_modbus_logical: SetState called from Modbus::ControlSet with active sets state and STATE to active
2020.11.01 12:12:07.576 3: infini_modbus_logical: RegisterAtIODev called from Modbus::SetLDActive registers infini_modbus_logical at infini_modbus_physical with id 1, MODE slave, PROTOCOL RTU
2020.11.01 12:12:07.577 3: infini_modbus_logical: using infini_modbus_physical for communication
2020.11.01 12:12:07.578 5: infini_modbus_physical: read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005
2020.11.01 12:12:07.578 5: infini_modbus_physical: ParseFrameStart called from Modbus::ReadFn
2020.11.01 12:12:07.579 4: infini_modbus_physical: ParseFrameStart (RTU) extracted id 1, fCode 4 and data 003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002
2020.11.01 12:12:07.579 5: infini_modbus_physical: HandleRequest called from Modbus::ReadFn
2020.11.01 12:12:07.580 5: infini_modbus_physical: ParseRequest called from Modbus::HandleRequest
2020.11.01 12:12:07.580 5: infini_modbus_physical: CheckChecksum (called from Modbus::HandleRequest): 3005 is valid
2020.11.01 12:12:07.581 4: infini_modbus_physical: HandleRequest, current frame / read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2
2020.11.01 12:12:07.581 5: infini_modbus_physical: GetLogHash returns hash for device infini_modbus_logical
2020.11.01 12:12:07.582 5: infini_modbus_logical: CreateResponse called from Modbus::HandleRequest
2020.11.01 12:12:07.582 5: infini_modbus_logical: PackObj called from Modbus::CreateResponse with i 52 and valuesLen 2
2020.11.01 12:12:07.583 4: infini_modbus_logical: PackObj for i52 is using reading 4_modbus of device Stromzaehler with value -2
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj packed -2 with pack code f>1 to c0000000
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj padded / cut object to c0000000
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj full data string is c0000000
2020.11.01 12:12:07.584 5: infini_modbus_logical: PackObj padded / cut data string to c0000000
2020.11.01 12:12:07.585 5: infini_modbus_logical: CreateResponse calls PackFrame to prepare response pdu
2020.11.01 12:12:07.585 5: infini_modbus_physical: PackResponse called from Modbus::CreateResponse
2020.11.01 12:12:07.586 4: infini_modbus_logical: CreateResponse sends response: id 1, fc 4 i52, len 2, value c0000000, device infini_modbus_logical (RTU), pdu 0404c0000000, V 4.3.2 - 30.10.2020
2020.11.01 12:12:07.586 5: infini_modbus_physical: Send called from Modbus::CreateResponse
2020.11.01 12:12:07.586 5: SW: 010404c0000000c784
2020.11.01 12:12:07.588 4: infini_modbus_physical: RequestDone, current frame / read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2,

Hier sieht man, dass im read buffer offensichtlich Anfragen angesammelt wurden:

Code Auswählen Erweitern


2020.11.01 12:12:07.588 4: infini_modbus_physical: RequestDone, current frame / read buffer: 01040034000230050104003400023005010400340002300501040034000230050104003400023005010400340002300501040034000230050104003400023005, id 1, fCode 4,
request: id 1 fc 4 i52, len 2,


Normalzustand:

Code Auswählen Erweitern


2020.11.01 12:12:08.231 5: infini_modbus_physical: read buffer: 0104003400023005



Ich hoffe, ich denke jetzt nicht völlig in die falsche Richtung... Falls doch, hole mich bitte wieder ins Boot

Danke,
Stephan

edit:
ich entnehme aber dem Kontext, dass der Master (also der der Abfragt) mit Fehlverhalten des Slaves klarkommen muss.
Tut er bisher auch - glaube ich.

[StefanStrobel]

Hallo Stephan,

ich hab mir das mal näher angesehen und Du hast recht, da hat etwas nicht so funktioniert wie es sollte. Der Slave hat im inaktiven Zustand die Anfragen nicht wirklich abgewiesen sondern die sind ungelesen im "seriellen Device" liegen geblieben. Ich habe das korrigiert.
Anbei eine neue Version.

Die Definitionen zu "Master" und "Slave" bzw. zum Modbus-Protokoll findest Du übrigens hier: https://modbus.org/specs.php

Gruss
   Stefan

[abc2006]

Hallo Stephan,

ich hab mir das mal näher angesehen und Du hast recht, da hat etwas nicht so funktioniert wie es sollte. Der Slave hat im inaktiven Zustand die Anfragen nicht wirklich abgewiesen sondern die sind ungelesen im "seriellen Device" liegen geblieben. Ich habe das korrigiert.
Anbei eine neue Version.

Guten Morgen,
die neue Version funktioniert.
Ich bin aber nicht sicher, ob die Fehlermeldung etwas irreführend sein könnte:

Code Auswählen Erweitern

DropBuffer for Modbus::ReadFn clears the reception buffer with 0104 mode or protocol not set
Ist aber nur ein Unschönheit, tut der Funktion keinen Abbruch.

Die Definitionen zu "Master" und "Slave" bzw. zum Modbus-Protokoll findest Du übrigens hier: https://modbus.org/specs.php

Ich fühle mich in meiner Ansicht bestätigt, dass der Wechselrichter der Master ist

Danke für deine Arbeit!

Viele Grüße,
Stephan

[Hollo]

...
Die Definitionen zu "Master" und "Slave" bzw. zum Modbus-Protokoll findest Du übrigens hier: https://modbus.org/specs.php

Die Modbus Organisation hat im Übrigen aufgrund der "aktuellen Unruhen und Debatten" Ihre Spec dahingehend geändert,
dass auf die Verwendung der Begriffe "Master" uns "Slave" verzichtet werden soll.
Stattdessen sollen auch hier die Begriffe "Client" und "Server" verwendet werden; wie es bei Modbus TCP eigentlich üblich ist.

Quelle:  https://modbus.org/docs/Client-ServerPR-07-2020-final.docx.pdf

Das macht vielleicht auch das Verständnis einfacher...

Slave = Server = stellt Daten zur Verfügung
Master = Client = ruft die Daten ab

[StefanStrobel]

Puh, ich bin nicht sicher ob ich Spaß daran habe jedes Vorkommen von "Master" im Modul und in der Dokumentation durch "Client" zu ersetzen... 

Gruss
    Stefan

[Roger]

Hi Stefan,
in 98_Modbus.pm ist ein readingsEndUpdate($hash, 0) drin - also ohne Events zu generieren. Dabei geht es um die Profiler-Readings. Ich möchte auf das Update von Profiler_Idle_sum triggern.
Was ist der Grund dieses eine readingsEndUpdate ohne Event auszuführen?
Kannst Du es auf Eventgenerierung (also mit 1) umstellen? (Notfalls durch Attr steuerbar.)

//Roger

[StefanStrobel]

Hallo Roger,

hier eine neue Version, die auch für Profiler-Readings Events erzeugt. Ich vermute ich habe das damals ohne Event gemacht, um die Fhem-Last geringer zu halten. Das sollte in diesem Fall aber nicht relevant sein.

Funktioniert das neue Basis-Modul ansonsten mit Deinem Modul?

Gruss
   Stefan

[Roger]

Hi Stefan,
die neue Version bringt FHEM zum Absturz  .

Code Auswählen Erweitern


2020.11.06 20:57:10.444 1: PERL WARNING: Use of uninitialized value $oldE in string ne at /usr/lipo/fhem/FHEM/98_Modbus.pm line 4318, <$fh> line 20.
2020.11.06 20:57:10.445 1: PERL WARNING: Use of uninitialized value $oldE in concatenation (.) or string at /usr/lipo/fhem/FHEM/98_Modbus.pm line 4318, <$fh> line 20.
Undefined subroutine &Modbus::Profiler called at /usr/lipo/fhem/FHEM/98_Modbus.pm line 1748, <$fh> line 20.


//Roger

[StefanStrobel]

Oh, ich sehe schon wo das Problem ist.
Sorry.
Neue Version kommt.

Gruß
    Stefan

[McBasil]

Hallo Stefan,

ich habe die neue Version an meiner Wärmepumpe eingesetzt. Sie läuft zufriedenstellend. Es werden zwei PERL-Warnungen ausgegeben.

Es gibt ein unschönes Verhalten, dem bin ich nachgegangen. Unter bestimmten Voraussetzungen führt das Setzen von Variablen aus einer Map heraus nicht zum Treffer, obwohl die Auswahl aus der Map entnommen vorgegeben wird. Die Ursache liegt in der Funktion MapConvert. Wenn man die Funktion traced ist zu sehen, dass inVal und Map in UTF-8 Codierung vorliegen. Offensichtlich werden Space, die in Map vorhanden sind, im Set-Procedere in nbsp verwandelt (warum auch immer) und erscheinen dann in inVal als nbsp. Damit kann inVal nicht mehr zum Treffer mit Map führen, denn die Strings sind jetzt unterschiedlich. Der Decode verbessert die Bedingungen nicht, vielmehr ist anzunehmen, dass jetzt  der Vergleich wegen unterschiedlicher Codierungen keinesfalls zum Treffer führen kann. Zum Ziel führt nur die Substitution der nbsp durch space in inVal in UTF-8.

Um Überraschungen bei der Reversmap, wenn der hash-key Leerzeichen enthält, vorzubeugen, habe ich die Spaces für den Reversvergleich durch das "?" maskiert.

Ich schlage vor die Funktion wie folgt zu ändern:

Code Auswählen Erweitern

sub MapConvert {
    my $hash    = shift;
    my $oRef    = shift;                                        # hash ref for passing options and variables for use in expressions

    my $map            = $oRef->{'map'} // '';                  # map to use
    my $reverse        = $oRef->{'reverse'} // 0;               # use reverse map
    my $action         = $oRef->{'action'} // 'apply map';      # context for logging
    my $UndefIfNoMatch = $oRef->{'undefIfNoMatch'} // 0;        # return undef if map is not matching,
    my $inVal          = $oRef->{'val'} // '';                  # input value
    my $name           = $hash->{NAME};
   
    return $inVal if (!$map);                                   # don't change anyting if map is empty

    my $val = $inVal;                       # subst all nbsp by space
    $map =~ s/\s+/ /g;                                          # substitute all \t \n etc. by one space only       
    $val =~ s/\xc2\xa0/ /g;                                    # subst all nbsp by space

    # spaces in words allowed,     separator is ',' or ':',     hash-key do not allowe spaces
    if ($reverse) { #
        $map =~ s/([^, ][^,\$]*):([^,][^,\$]*),? */$2:$1, /g;   # reverse map
$map =~ s/ /?/g;                                        # mask spaces for hash-key
$val =~ s/ /?/g;                                          # mask spaces for hash-key
$map =~ s/,\?/, /g;                                     # mask spaces for separation
    }

    my %mapHash = split (/, *|:/, $map);                       # reverse hash aus dem reverse string                   

    if (defined($mapHash{$val})) {                                  # Eintrag für den übergebenen Wert in der Map?
        my $newVal = $mapHash{$val};                            # entsprechender Raw-Wert für das Gerät
        Log3 $name, 5, "$name: MapConvert called from " . FhemCaller() . " converted $val to $newVal with" .
        ($reverse ? " reversed" : "") . " map $map";
        return $newVal;
    }
    else {
        Log3 $name, 3, "$name: MapConvert called from " . FhemCaller() . " did not find $val in" .
        ($reverse ? " reversed" : "") . " map $map";
        return if ($UndefIfNoMatch);
        return $inVal;
    }
}

und hier noch der Trace:

Code Auswählen Erweitern

2020.11.06 15:46:33 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 2953.
2020.11.06 15:46:33 2: Wi18Tu: MapConvert mit inval <2. Wärmeerzeuger> suchen in Map <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2. Wärmeerzeuger:4, Kühlen:5, >
2020.11.06 15:46:33 2: Wi18Tu: MapConvert inval                 <2. Wärmeerzeuger>   <50 46 194 160 87 195 164 114 109 101 101 114 122 101 117 103 101 114>
2020.11.06 15:46:33 2: Wi18Tu: MapConvert inval nach Decode     <2. W�rmeerzeuger>   <50 46 160 87 228 114 109 101 101 114 122 101 117 103 101 114>>   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert inval nach Substitute <2. W�rmeerzeuger>   <50 46 32 87 228 114 109 101 101 114 122 101 117 103 101 114>   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Keys   Party Automatik 2. Wärmeerzeuger Kühlen Urlaub Sommer   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Map   <S  o   m   m   e   r   :  0  , ' ' A  u   t   o   m   a  t   i   k   :  1  , ' ' U  r   l   a  u   b  :  2  , ' ' P  a  r   t   y   :  3  , ' ' 2  . ' ' W  ä       r   m   e   e   r   z   e   u   g   e   r   :  4  , ' ' K  ü       h   l   e   n   :  5  , ' '>
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Keys  <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 32 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.06 15:46:33 2: Wi18Tu: MapConvert Values <3 1 4 5 2 0> 
2020.11.06 15:46:33 3: Wi18Tu: MapConvert called from Modbus::FormatSetVal did not find 2. W�rmeerzeuger in reversed map Sommer:0, Automatik:1, Urlaub:2, Party:3, 2. Wärmeerzeuger:4, Kühlen:5,



2020.11.07 00:59:50 3: Opening Wi18Tu device ECS-AP:8899
2020.11.07 00:59:50 0: Featurelevel: 6
2020.11.07 00:59:50 0: Server started with 16 defined entities (fhem.pl:22990/2020-10-19 perl:5.028001 os:linux user:fhem pid:9809)
2020.11.07 00:59:50 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 2953.
2020.11.07 00:59:50 3: Wi18Tu device opened
2020.11.07 00:59:59 2: Wi18Tu: MapConvert mit inval <Automatik> suchen in Map <0:Sommer,1:Automatik,2:Urlaub,3:Party,4:2. Wärmeerzeuger,5:Kühlen>
2020.11.07 00:59:59 2: Wi18Tu: MapConvert inval                 <Automatik>   <65 117 116 111 109 97 116 105 107>
2020.11.07 00:59:59 2: Wi18Tu: MapConvert inval nbsp->space     <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert inval nach Substitute <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Keys   <Urlaub Automatik Kühlen 2.?Wärmeerzeuger Party Sommer>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Map    <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2.?Wärmeerzeuger:4, Kühlen:5, >
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Keys   <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.07 00:59:59 2: Wi18Tu: MapConvert Values <2 1 5 4 3 0>   
2020.11.07 00:59:59 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3697.
2020.11.07 01:00:05 2: Wi18Tu: MapConvert mit inval <2. Wärmeerzeuger> suchen in Map <0:Sommer,1:Automatik,2:Urlaub,3:Party,4:2. Wärmeerzeuger,5:Kühlen>
2020.11.07 01:00:05 2: Wi18Tu: MapConvert inval                 <2. Wärmeerzeuger>   <50 46 194 160 87 195 164 114 109 101 101 114 122 101 117 103 101 114>
2020.11.07 01:00:05 2: Wi18Tu: MapConvert inval nbsp->space     <2. Wärmeerzeuger>   <50 46 32 87 195 164 114 109 101 101 114 122 101 117 103 101 114>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert inval nach Substitute <2.?Wärmeerzeuger>   <50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Keys   <Urlaub Automatik Kühlen 2.?Wärmeerzeuger Party Sommer>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Map    <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2.?Wärmeerzeuger:4, Kühlen:5, >
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Keys   <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.07 01:00:05 2: Wi18Tu: MapConvert Values <2 1 5 4 3 0>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert mit inval <Automatik> suchen in Map <0:Sommer,1:Automatik,2:Urlaub,3:Party,4:2. Wärmeerzeuger,5:Kühlen>
2020.11.07 01:00:12 2: Wi18Tu: MapConvert inval                 <Automatik>   <65 117 116 111 109 97 116 105 107>
2020.11.07 01:00:12 2: Wi18Tu: MapConvert inval nbsp->space     <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert inval nach Substitute <Automatik>   <65 117 116 111 109 97 116 105 107>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Keys   <Urlaub Automatik Kühlen 2.?Wärmeerzeuger Party Sommer>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Map    <Sommer:0, Automatik:1, Urlaub:2, Party:3, 2.?Wärmeerzeuger:4, Kühlen:5, >
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Keys   <83 111 109 109 101 114 58 48 44 32 65 117 116 111 109 97 116 105 107 58 49 44 32 85 114 108 97 117 98 58 50 44 32 80 97 114 116 121 58 51 44 32 50 46 63 87 195 164 114 109 101 101 114 122 101 117 103 101 114 58 52 44 32 75 195 188 104 108 101 110 58 53 44 32>   
2020.11.07 01:00:12 2: Wi18Tu: MapConvert Values <2 1 5 4 3 0>   

2020.11.07 01:12:34 3: Opening Wi18Tu device ECS-AP:8899
2020.11.07 01:12:34 0: Featurelevel: 6
2020.11.07 01:12:34 0: Server started with 16 defined entities (fhem.pl:22990/2020-10-19 perl:5.028001 os:linux user:fhem pid:10359)
2020.11.07 01:12:34 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 2953.
2020.11.07 01:12:34 3: Wi18Tu device opened
2020.11.07 01:12:52 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_Modbus.pm line 3697.



Weiterhin ist mir aufgefallen, dass der FHEM-reload Befehl die Moduln immer unter ./FHEM/ sucht. Damit besteht keine Chance deine Moduln, die jetzt unter ./lib/ residieren, nachzuladen. Da hilft nur ein Restart.

Viel Grüße
Basil

[StefanStrobel]

Hallo Basil,

zum Hintergrund der der  -Geschichte:
Die Maps werden meist auch als Hints in Fhemweb verwendet, so dass man im Browser-GUI bei einem Set-Befehl aus einer Liste von Werten auswählen kann. Damit das funktioniert, kann das Space-Zeichen nicht einfach so als Hint übergeben werden.
Die damals naheliegende Lösung war das  . (siehe MapToHint). Entsprechend muss   aus einem Set-Befehl wieder zurück in ein Space gewandelt werden.
Inzwischen scheint sich in Fhemweb etwas geändert zu haben, denn statt dem   kommt beim Set ein utf-8 nbsp (\xc2\xa0) zurück.
Zudem macht das decode Ärger mit den Umlauten.
Ich bin dabei das umzubauen und poste eine neue Version sobald ich es testen konnte.

Das mit dem reload ist ein bekanntes Problem mit Bibliotheks-Funktionen.
Das kann ich aber nicht im Modbus-Modul lösen. Daher kommt übrigens auch der Fehler, den Roger gemeldet hat. Nach einem Neustart (wenn auch die Utils neu geladen sind), sollte kein Undefined subroutine &Modbus::Profiler mehr kommen.

Gruss
   Stefan

[StefanStrobel]

Hier eine neue Version, bei der kein decode mehr auf set -Werte gemacht wird und auch utf8-nbsp vor Anwendung einer Map in ein normales Space gewandelt wird.
Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD und wird erst beim Neustart von Fhem geladen.

Gruss
   Stefan

[Roger]

Hi Stefan,

Das mit dem reload ist ein bekanntes Problem mit Bibliotheks-Funktionen.
Das kann ich aber nicht im Modbus-Modul lösen. Daher kommt übrigens auch der Fehler, den Roger gemeldet hat. Nach einem Neustart (wenn auch die Utils neu geladen sind), sollte kein Undefined subroutine &Modbus::Profiler mehr kommen.

Ich hatte einen anderen Fehler. Ich hatte nicht mitbekommen, das Utils.pm nicht nach FHEM kommt. 

Code Auswählen Erweitern

Utils.pm gehört ins Verzeichnis lib/FHEM/HTTPMOD
Allerdings habe ich es nach FHEM/lib/HTTPMOD kopiert. War das richtig?
Damit stürzt FHEM beim Start zumindest nicht mehr ab.

//Roger