Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo holle75,

wenn Du die Länge von i1 auf 4 setzt, dann wird das ein einziges Reading. Statt dessen musst Du mit obj-i1-group arbeiten (siehe https://forum.fhem.de/index.php?topic=75638.msg1129957#msg1129957)

if / then geht innerhalb des Moduls nicht. Das muss Fhem machen. Z.B. aus einem doif ein get auf ein Modbus-Objekt ...

Gruß   
   Stefan

[StefanStrobel]

Hallo fireball,

device löschen und neu anlegen erscheint mir nicht überzeugend als Lösung.
Es wäre schön zu verstehen, wer die Verbindung ständig schließt. Wenn das der Wechselrichter ist, dann kannst Du mit  closeAfterResponse verhindern, dass Fhem die Verbindung sofort wieder neu aufmacht.
Hilfreich wäre ein Auszug aus dem Log bei verbose 5.

Gruß
   Stefan

[stobor]

Hallo,

ich habe gerade einen Eastron SDM630-Modbus V2 Energiezähler über ein USB-zu-RS482/ModBus Adapter (DSD TECH SH-U11H) in Betrieb genommen.
Die Verbidnung (ca. 2m Kabellänge) ist beidseitig mit 120ohm terminiert.

Meine derzeitige (minimale) Konfiguration in der fhem.cfg sieht so aus:

Code Auswählen Erweitern

define ModBusUSBAdapter Modbus /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0@9600
setuuid ModBusUSBAdapter 6479081c-f33f-2cfb-4355-7c2c3d9340c8fada
attr ModBusUSBAdapter room ModBus

define HA_SDM630M_1 ModbusSDM630M 2 60
setuuid HA_SDM630M_1 6479081c-f33f-2cfb-cb6f-8dd2c90129580e77
attr HA_SDM630M_1 userattr IODev
attr HA_SDM630M_1 IODev ModBusUSBAdapter
attr HA_SDM630M_1 room ModBus
Zunächst bin ich überrascht, dass ich keinerlei weitere Parameter bzgl. der Verbindung angeben musste (Stopp-Bit, Parität, ...). Das wurde anscheinend automatisch ausgehandelt/ vom SDM übernommen.

Im Log finde ich derzeit (nur) das:

Code Auswählen Erweitern

2023.06.02 07:57:39 3: HA_SDM630M_1: RegisterAtIODev called from SetIODev registers HA_SDM630M_1 at ModBusUSBAdapter with id 2, MODE master, PROTOCOL RTU
2023.06.02 07:57:39 3: HA_SDM630M_1: Notify / Init: using ModBusUSBAdapter for communication
2023.06.02 07:57:39 3: Opening ModBusUSBAdapter device /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_BLAZb113318-if00-port0
2023.06.02 07:57:39 3: Setting ModBusUSBAdapter serial parameters to 9600,8,N,1
2023.06.02 07:57:39 3: ModBusUSBAdapter device opened
Ca 40min nach dem FHEM Neustart kommt dann auch das hier:

Code Auswählen Erweitern

...
2023.06.02 16:34:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:34:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:06 3: delete PIR_CP_aus : Please define PIR_CP_aus first
2023.06.02 16:36:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i46, len 40, master device HA_SDM630M_1, reading Current_Avr__A (getUpdate for combined i46 len 2 Current_Avr__A with i48 len 2 Current_Sum__A and i52 len 2 Power_Sum__W and i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:29 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i224, len 2, master device HA_SDM630M_1, reading Current_N__A (getUpdate for Current_N__A len 2), queued 6.01 secs ago, sent 2.00 secs ago
2023.06.02 16:36:40 3: FS20 set Bewegungsmelder_Sued_West off
2023.06.02 16:37:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
...
Trotzdem werden mir schon die Readings angezeigt - siehe Screenshot anbei. Diese aktualisieren sich aber nach einiger Zeit nur noch sporadisch - vielleicht alle 40min-1h.

Leider werden die Readings nicht dauerhaft verlässlich und zeitnah aktualisiert. Was muss ich tun, damit diese immer aktuell sind?


Vielen Dank für eure Hilfe.

[holle75]

wenn Du die Länge von i1 auf 4 setzt, dann wird das ein einziges Reading. Statt dessen musst Du mit obj-i1-group arbeiten (siehe https://forum.fhem.de/index.php?topic=75638.msg1129957#msg1129957)

Vielen Dank Stefan! Das wars.

Wer einen Studer Gateway abfragen möchte:

Code Auswählen Erweitern

define Studer485_Gateway ModbusAttr 33 55
attr Studer485_Gateway dev-defPoll 1
attr Studer485_Gateway dev-defUnpack n
attr Studer485_Gateway dev-i-read 4
attr Studer485_Gateway dev-timing-timeout 1
attr Studer485_Gateway group Xtender
attr Studer485_Gateway obj-i0-len 1
attr Studer485_Gateway obj-i0-reading Message_Count_must_read_first
attr Studer485_Gateway obj-i1-group 1-1
attr Studer485_Gateway obj-i1-len 1
attr Studer485_Gateway obj-i1-map 11:XTM,21:VT,61:BSP
attr Studer485_Gateway obj-i1-reading Last_Message_Device
attr Studer485_Gateway obj-i2-group 1-2
attr Studer485_Gateway obj-i2-len 1
attr Studer485_Gateway obj-i2-map 0:Warning (000) - Battery too low,1:Warning (001) - Battery too high,2:Warning (002) - Bulk charge too long,3:(003) - AC-In synchronization in progress,4:Warning (004) - Input frequency AC-In wrong,5:Warning (005) - Input frequency AC-In wrong,6:Warning (006) - Input voltage AC-In too high,7:Warning (007) - Input voltage AC-In too low,8:Halted (008) - Inverter overload SC,9:Halted (009) - Charger short circuit,10:(010) - System start-up in progress,11:Warning (011) - AC-In Energy quota,12:(012) - Use of battery temperature sensor,13:(013) - Use of additional remote control,14:Halted (014) - Over temperature EL,15:Halted (015) - Inverter overload BL,16:Warning (016) - Fan error detected,17:(017) - Programing mode,18:Warning (018) - Excessive battery voltage ripple,19:Halted (019) - Battery undervoltage,20:Halted (020) - Battery overvoltage,21:(021) - Transfer not authorized, AC-Out current is higher than {1107},22:Halted (022) - Voltage presence on AC-Out,23:Halted (023) - Phase not defined,24:Warning (024) - Change the clock battery,25:Halted (025) - Unknown Command board. Software upgrade needed,26:Halted (026) - Unknown Power board. Software upgrade needed,27:Halted (027) - Unknown extension board. Software upgrade needed,28:Halted (028) - Voltage incompatibility Power - Command,29:Halted (029) - Voltage incompatibility Ext. - Command,30:Halted (030) - Power incompatibility Power - Command,31:Halted (031) - Command board software incompatibility,32:Halted (032) - Power board software incompatibility,33:Halted (033) - Extension board software incompatibility,34:Halted (034) - FID corruption, call factory,35:(035) - Memory structure modified,36:Halted (036) - Parameter file lacking,37:Warning (037) - Message file lack. SW upgrade advised,38:Warning (038) - Upgrade of the device software advised,39:Warning (039) - Upgrade of the device software advised,40:Warning (040) - Upgrade of the device software advised,41:Warning (041) - Over temperature TR,42:Halted (042) - Unauthorized energy source at the output,43:(043) - Start of monthly test,44:(044) - End of successfully monthly test,45:Warning (045) - Monthly autonomy test failed,46:(046) - Start of weekly test,47:(047) - End of successfully weekly test,48:Warning (048) - Weekly autonomy test failed,49:(049) - Transfer opened because AC-In max current exceeded {1107},50:Error (050) - Incomplete data transfer,51:(051) - The update is finished,52:(052) - Your installation is already updated,53:Halted (053) - Devices not compatible, software update required,54:(054) - Please wait. Data transfer in progress,55:Error (055) - No SD card inserted,56:Warning (056) - Upgrade of the RCC software advised,57:(057) - Operation finished successfully,58:Halted (058) - Master synchronization missing,59:Halted (059) - Inverter overload HW,60:Warning (060) - Time security 1512 AUX1,61:Warning (061) - Time security 1513 AUX2,62:Warning (062) - Genset, no AC-In coming after AUX command,63:(063) - Save parameter XT,64:(064) - Save parameter BSP,65:(065) - Save parameter VarioTrack,71:Error (071) - Insufficient disk space on SD card,72:Halted (072) - COM identification incorrect,73:(073) - Datalogger is enabled on this RCC,74:(074) - Save parameter Xcom-MS,75:(075) - MPPT MS address changed successfully,76:Error (076) - Error during change of MPPT MS address,77:Error (077) - Wrong MPPT MS DIP Switch position,78:(078) - SMS or email sent,79:Halted (079) - More than 9 XTs in the system,80:Halted (080) - No battery (or reverse polarity),81:Warning (081) - Earthing fault,82:Halted (082) - PV overvoltage,83:Warning (083) - No solar production in the last 48h,84:(084) - Equalization performed,85:Error (085) - Modem not available,86:Error (086) - Incorrect PIN code, unable to initiate the modem,87:Error (087) - Insufficient Signal from GSM modem,88:Error (088) - No connection to GSM network,89:Error (089) - No Xcom server access,90:(090) - Xcom server connected,91:Warning (091) - Update finished. Update software of other RCC/Xcom-232i,92:Error (092) - More than 4 RCC or Xcom in the system,93:Error (093) - More than 1 BSP in the system,94:Error (094) - More than 1 Xcom-MS in the system,95:Error (095) - More than 15 VarioTrack in the system,121:Error (121) - Impossible communication with target device,122:Error (122) - SD card corrupted,123:Error (123) - SD card not formatted,124:Error (124) - SD card not compatible,125:Error (125) - SD card format not recognized. Should be FAT,126:Error (126) - SD card write protected,127:Error (127) - SD card, file(s) corrupted,128:Error (128) - SD card file or directory could not be found,129:Error (129) - SD card has been prematurely removed,130:Error (130) - Update directory is empty,131:(131) - The VarioTrack is configured for 12V batteries,132:(132) - The VarioTrack is configured for 24V batteries,133:(133) - The VarioTrack is configured for 48V batteries,134:(134) - Reception level of the GSM signal,137:(137) - VarioTrack master synchronization lost,138:Error (138) - XT master synchronization lost,139:(139) - Synchronized on VarioTrack master,140:(140) - Synchronized on XT master,141:Error (141) - More than 1 Xcom-SMS in the system,142:Error (142) - More than 15 VarioString in the system,143:(143) - Save parameter Xcom-SMS,144:(144) - Save parameter VarioString,145:Error (145) - SIM card blocked, PUK code required,146:Error (146) - SIM card missing,147:Error (147) - Install R532 firmware release prior to install an older release,148:(148) - Datalogger function interrupted (SD card removed),149:Error (149) - Parameter setting incomplete,150:Error (150) - Cabling error between PV and VarioString,162:Error (162) - Communication loss with RCC or Xcom-232i,163:Error (163) - Communication loss with Xtender,164:Error (164) - Communication loss with BSP,165:Error (165) - Communication loss with Xcom-MS,166:Error (166) - Communication loss with VarioTrack,167:Error (167) - Communication loss with VarioString,168:(168) - Synchronized with VarioString master,169:(169) - Synchronization with VarioString master lost,170:Warning (170) - No solar production in the last 48h on PV1,171:Warning (171) - No solar production in the last 48h on PV2,172:Error (172) - FID change impossible. More than one unit.,173:Error (173) - Incompatible Xtender. Please contact Studer Innotec SA,174:(174) - Inaccessible parameter, managed by the Xcom-CAN,175:Halted (175) - Critical undervoltage,176:(176) - Calibration setting lost,177:(177) - An Xtender has started up,178:(178) - No BSP. Necessary for programming with SOC,179:(179) - No BTS or BSP. Necessary for programming with temperature,180:(180) - Command entry activated,181:Error (181) - Disconnection of BTS,182:(182) - BTS/BSP battery temperature measurement used by a device,183:Halted (183) - An Xtender has lost communication with the system,184:Error (184) - Check phase orientation or circuit breakers state on AC-In,185:Warning (185) - AC-In voltage level with delay too low,186:Halted (186) - Critical undervoltage (fast),187:Halted (187) - Critical overvoltage (fast),188:(188) - CAN stage startup,189:Error (189) - Incompatible configuration file,190:(190) - The Xcom-SMS is busy,191:(191) - Parameter not supported,192:(192) - Unknown reference,193:(193) - Invalid value,194:(194) - Value too low,195:(195) - Value too high,196:(196) - Writing error,197:(197) - Reading error,198:(198) - User level insufficient,199:(199) - No data for the report,200:Error (200) - Memory full,202:Warning (202) - Battery alarm arrives,203:(203) - Battery alarm leaves,204:Error (204) - Battery stop arrives,205:(205) - Battery stop leaves,206:Halted (206) - Board hardware incompatibility,207:(207) - AUX1 relay activation,208:(208) - AUX1 relay deactivation,209:(209) - AUX2 relay activation,210:(210) - AUX2 relay deactivation,211:(211) - Command entry deactivated,212:Error (212) - VarioTrack software incompatibility. Upgrade needed,213:(213) - Battery current limitation by the BSP stopped,214:Warning (214) - Half period RMS voltage limit exceeded, transfer opened,215:Warning (215) - UPS limit reached, transfer opened,216:Warning (216) - Scom watchdog caused the reset of Xcom-232i,217:Warning (217) - CAN problem at Xtender declaration,218:Warning (218) - CAN problem while writing parameters,222:(222) - Front ON/OFF button pressed,223:(223) - Main OFF detected,224:(224) - Delay before closing transfer relay in progress {1580},225:Error (225) - Communication with lithium battery lost,226:(226) - Communication with lithium battery restored,227:Error (227) - Overload on high voltage DC side,228:Error (228) - Startup error,229:Error (229) - Short-circuit on high voltage DC side
attr Studer485_Gateway obj-i2-reading Last_Message_Info
attr Studer485_Gateway obj-i3-group 1-3
attr Studer485_Gateway obj-i3-len 1
attr Studer485_Gateway obj-i3-reading Last_Message_ignore1
attr Studer485_Gateway obj-i4-group 1-4
attr Studer485_Gateway obj-i4-len 1
attr Studer485_Gateway obj-i4-reading Last_Message_ignore2

Edit: Mmh, nachdem ich jetzt freudig alle Messages ausgelesen habe (die jeweils danach gelöscht werden), ist mir die zweite Herausforderung (die ich verdrängt hatte) wieder bewußt geworden. Das Kästchen schmiert noch immer ab, wenn es keine Messages hat und ich sie trotzdem auslese. Ich werde mich mal mit deiner Empfehlung auseinandersetzen.

"if / then geht innerhalb des Moduls nicht. Das muss Fhem machen. Z.B. aus einem doif ein get auf ein Modbus-Objekt ..."

Stefan, könntest du hierzu ein ganz klein wenig elaborieren? get auf Modbus-Objekt klickt bei mir nicht ganz, resp. wie ich das getrennt bekomme.

- Abfrage wie jetzt auch, aber nur auf Anzahl Messages
- Anzahl 0 -> nichts tun
- Anzahl größer 0 -> DOIF triggern
- Aber wie dann im DOIF ein anderes Modbus-Device abfragen, was ansonsten nicht aktiv ist?

weitergedacht, allgemein poll aus und nur Message_Count regelmäßig abfragen. .....
- aber, da ich ja in einem Durchlauf immer erst Message_Count abfragen muss und danach erst die Message, wie kombiniere ich das in einem DOIF mit gets?
- erschwerend kommt hinzu, dass Message_Count, wenn leer, nicht brav 0 sondern 65535 liefert. Aber immerhin konstant und entspricht somit 0 .... und das Kästchen schmiert nicht ab wenn ich nur diesen Wert polle.

noch mehr weitergedacht. Vielleicht meint Studer mit ihrer Definition "must read first" nur, dass man eben Messages nur auslesen soll, wenn es welche gibt und gar nix von im selben Auslesevorgang oä ?! Also so hatte ich Trottel das verstanden.
kann ich ein get auf eine group absetzen? get Studer485_Gateway group 1

probiert, geht nicht (wär mal noch eine Idee)
wie kombiniere ich die gets im DOIF ?

[StefanStrobel]

Hallo holle75,

get auf groups ist bisher nicht implementiert, aber das ist eine sinnvolle Erweiterung. Das baue ich demnächst mal ein.
Bis dahin könntest Du folgendes machen:

wenn das Intervall beim define 0 ist, dann wird nicht automatisch gelesen, sondern bei einem

Code Auswählen Erweitern

set Studer485_Gateway reread.
Somit kannst Du über ein at regelmäßig per

Code Auswählen Erweitern

get Studer485_Gateway Message_Count_must_read_first prüfen, ob es was zu lesen gibt und dann per doif ein set reread auslösen.

Gruss
  Stefan

[StefanStrobel]

Hallo stobor,

Zunächst bin ich überrascht, dass ich keinerlei weitere Parameter bzgl. der Verbindung angeben musste (Stopp-Bit, Parität, ...). Das wurde anscheinend automatisch ausgehandelt/ vom SDM übernommen.

Nein, das wird nicht ausgehandelt sondern der Default ist 8N1

Ca 40min nach dem FHEM Neustart kommt dann auch das hier:

Code Auswählen Erweitern

...
2023.06.02 16:34:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:34:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:06 3: delete PIR_CP_aus : Please define PIR_CP_aus first
2023.06.02 16:36:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i46, len 40, master device HA_SDM630M_1, reading Current_Avr__A (getUpdate for combined i46 len 2 Current_Avr__A with i48 len 2 Current_Sum__A and i52 len 2 Power_Sum__W and i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:29 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i224, len 2, master device HA_SDM630M_1, reading Current_N__A (getUpdate for Current_N__A len 2), queued 6.01 secs ago, sent 2.00 secs ago
2023.06.02 16:36:40 3: FS20 set Bewegungsmelder_Sued_West off
2023.06.02 16:37:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
...
Trotzdem werden mir schon die Readings angezeigt - siehe Screenshot anbei. Diese aktualisieren sich aber nach einiger Zeit nur noch sporadisch - vielleicht alle 40min-1h.
Leider werden die Readings nicht dauerhaft verlässlich und zeitnah aktualisiert. Was muss ich tun, damit diese immer aktuell sind?

Die Timeouts deuten auf Übertragungsfehler hin.
Evt. ist schon eine Terminierung eingebaut und doppelt terminiert kann Probleme verursachen. Oder mit dem Kabel stimmt was nicht.

Gruss
  Stefan

[holle75]

Danke Stefan, kleiner Ausflug zu "get". Habe jetzt das gebaut

Code Auswählen Erweitern

define Studer485_Gateway_Trigger_AT at +*00:00:55 get Studer485_Gateway Message_Count_must_read_first
attr Studer485_Gateway_Trigger_AT group Xtender

define Studer485_Gateway_Trigger_DOIF DOIF ([Studer485_Gateway:Message_Count_must_read_first] > 0 and [Studer485_Gateway:Message_Count_must_read_first] < 129) (set Studer485_Gateway reread)
attr Studer485_Gateway_Trigger_DOIF do always
attr Studer485_Gateway_Trigger_DOIF group Xtender

allerdings wirft mir das at keinen Event?? Get seltenst benutzt (ist das nicht blocking?) und auch das Forum gibt wenig Info.
Manuell gibt mir das get aus dem at ein Popup, aber auch keinen Event

Intervall und Poll habe ich so verändert:

Code Auswählen Erweitern

defmod Studer485_Gateway ModbusAttr 33 0
attr Studer485_Gateway dev-defPoll 1
attr Studer485_Gateway dev-defUnpack n
attr Studer485_Gateway dev-i-read 4
attr Studer485_Gateway dev-timing-timeout 1
attr Studer485_Gateway event-on-change-reading .*
attr Studer485_Gateway group Xtender
attr Studer485_Gateway obj-i0-len 1
attr Studer485_Gateway obj-i0-reading Message_Count_must_read_first
attr Studer485_Gateway obj-i1-group 1-1
attr Studer485_Gateway obj-i1-len 1
attr Studer485_Gateway obj-i1-map 11:XTM,21:VT,61:BSP
attr Studer485_Gateway obj-i1-reading Last_Message_Device
attr Studer485_Gateway obj-i2-group 1-2
attr Studer485_Gateway obj-i2-len 1
attr Studer485_Gateway obj-i2-reading Last_Message_Info
attr Studer485_Gateway obj-i3-group 1-3
attr Studer485_Gateway obj-i3-len 1
attr Studer485_Gateway obj-i3-reading Last_Message_ignore1
attr Studer485_Gateway obj-i4-group 1-4
attr Studer485_Gateway obj-i4-len 1
attr Studer485_Gateway obj-i4-reading Last_Message_ignore2

was mache ich falsch?

Edit: oh, stattdessen bekomme ich jetzt alle 55 Sekunden einen fhem logeintrag ... ok, at auch nur seltenst genutzt. Muss mich wohl mal mit at schlau machen.
Edit2: DOIF gebaut, nicht wirklich erfolgreich. get scheint nicht mein Freund zu sein.

Code Auswählen Erweitern

#define Studer485_Gateway_Trigger_Timer_DOIF DOIF {[00:00-23:59,+00:00:55];;fhem_set"get Studer485_Gateway Message_Count_must_read_first"}

#define Studer485_Gateway_Trigger_Timer_DOIF DOIF ([00:00-23:59,+00:00:55])(get Studer485_Gateway Message_Count_must_read_first)
Wie löst man fachgerecht ein get in fhem aus?

[holle75]

Ha, das DOIF wirft errors, aber das AT funktioniert plötzlich ... sehr seltsam

Allerdings würde ich dem AT gerne sagen, dass es NICHT ins fhem log jedes Ergebnis schreibt. Wie lässt sich das vermeiden?

die Kombo funktioniert

Code Auswählen Erweitern

define Studer485_Gateway_Trigger_AT at +*00:00:55 get Studer485_Gateway Message_Count_must_read_first

define Studer485_Gateway_Trigger_DOIF DOIF ([Studer485_Gateway:Message_Count_must_read_first] > 0 and [Studer485_Gateway:Message_Count_must_read_first] < 129) (set Studer485_Gateway reread)
attr Studer485_Gateway_Trigger_DOIF do always

aber schreibt mir ins fhem log jede Ausführungsschleife des AT. Warum macht das AT das?

fhem.log

Code Auswählen Erweitern

2023.06.14 11:43:29 3: Studer485_Gateway_Trigger_AT: 66
2023.06.14 11:44:24 3: Studer485_Gateway_Trigger_AT: 65
2023.06.14 11:45:19 3: Studer485_Gateway_Trigger_AT: 64
2023.06.14 11:46:14 3: Studer485_Gateway_Trigger_AT: 63
2023.06.14 11:47:09 3: Studer485_Gateway_Trigger_AT: 62
2023.06.14 11:48:04 3: Studer485_Gateway_Trigger_AT: 61

EDIT: ja klar, verbose 2 ..... war mir entfallen
AT gefällt mir irgendwie nicht, das DOIF wär mir lieber. Falls jemand weiss, warum meine obige Konfi (post davor) nicht funktioniert, lasst gerne wissen. Werde auch mal im DOIF-Bereich nachhaken.
UND, falls jemand etwas zu get ist blocking oder nicht sagen kann, wär ich auch recht dankbar.

[stobor]

Hallo stobor,

Zunächst bin ich überrascht, dass ich keinerlei weitere Parameter bzgl. der Verbindung angeben musste (Stopp-Bit, Parität, ...). Das wurde anscheinend automatisch ausgehandelt/ vom SDM übernommen.

Nein, das wird nicht ausgehandelt sondern der Default ist 8N1

Ca 40min nach dem FHEM Neustart kommt dann auch das hier:

Code Auswählen Erweitern

...
2023.06.02 16:34:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:34:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i12, len 38, master device HA_SDM630M_1, reading Power_L1__W (getUpdate for combined i12 len 2 Power_L1__W with i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V and i46 len 2 Current_Avr__A and i48 len 2 Current_Sum__A), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:35:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i52, len 34, master device HA_SDM630M_1, reading Power_Sum__W (getUpdate for combined i52 len 2 Power_Sum__W with i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:06 3: delete PIR_CP_aus : Please define PIR_CP_aus first
2023.06.02 16:36:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:27 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i46, len 40, master device HA_SDM630M_1, reading Current_Avr__A (getUpdate for combined i46 len 2 Current_Avr__A with i48 len 2 Current_Sum__A and i52 len 2 Power_Sum__W and i84 len 2 Power_Sum_demand__W), queued 4.00 secs ago, sent 2.00 secs ago
2023.06.02 16:36:29 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i224, len 2, master device HA_SDM630M_1, reading Current_N__A (getUpdate for Current_N__A len 2), queued 6.01 secs ago, sent 2.00 secs ago
2023.06.02 16:36:40 3: FS20 set Bewegungsmelder_Sued_West off
2023.06.02 16:37:25 3: ModBusUSBAdapter: Timeout waiting for a modbus response, read buffer empty,
request: id 2, read fc 4 i6, len 38, master device HA_SDM630M_1, reading Current_L1__A (getUpdate for combined i6 len 2 Current_L1__A with i8 len 2 Current_L2__A and i10 len 2 Current_L3__A and i12 len 2 Power_L1__W and i14 len 2 Power_L2__W and i16 len 2 Power_L3__W and i42 len 2 Voltage_Avr__V), queued 2.00 secs ago, sent 2.00 secs ago
...
Trotzdem werden mir schon die Readings angezeigt - siehe Screenshot anbei. Diese aktualisieren sich aber nach einiger Zeit nur noch sporadisch - vielleicht alle 40min-1h.
Leider werden die Readings nicht dauerhaft verlässlich und zeitnah aktualisiert. Was muss ich tun, damit diese immer aktuell sind?

Die Timeouts deuten auf Übertragungsfehler hin.
Evt. ist schon eine Terminierung eingebaut und doppelt terminiert kann Probleme verursachen. Oder mit dem Kabel stimmt was nicht.

Gruss
  Stefan

Jetzt läuft es bei mir.
Ich habe Delays bei den Attributen definiert:
dev-timing-commDelay = 0.5
dev-timing-sendDelay = 0.5

[Roger]

Hi Stefan,
ich habe mal meine exclude_from_update für die Modbus-Module weggenommen und ein update gemacht.
Nun läuft die dev-fc.*-Erweiterung nicht mehr.
Hat es die Erweiterung noch nicht ins offizielle Modul geschafft?
Wann hat Du das geplant?

//Roger

[/quote]

Anbei eine neue Version des Moduls zum Testen bevor ich es einchecke und es per update verteilt wird.
Man kann nun custom function codes selbst definieren, das Loglevel wurde bei einigen Events von 3 auf 4 erhöht und ein par Bugs gefixt.
Zudem sind einige Data types vordefiniert, so dass man meist keinen unpack code und keine len mehr angeben muss und der data type reicht.
Ich hoffe es funktioniert noch alles

Gruss
  Stefan

[StefanStrobel]

Hallo Roger,

danke für die Erinnerung. Habe es gerade eingecheckt. Bisher gab es ja keine Problem-Meldungen zur neuen Version.

Gruss
   Stefan

[StefanStrobel]

Hallo holle75,

get ist bei ModbusAttr blocking, es sei denn man setzt das Attribut nonPrioritizedGet (hat in der Doku leider gefehlt, da war nur nonPrioritizedSet drin).

Gruss
   Stefan

[Roger]

Hallo Roger,

danke für die Erinnerung. Habe es gerade eingecheckt. Bisher gab es ja keine Problem-Meldungen zur neuen Version.

Gruss
  Stefan

Hi Stefan,
habe neue Version eingespielt.

Bekomme (wie vorher manchmal auch):
Undefined subroutine &Modbus::HexIfNeeded called at 98_Modbus.pm line 2546

Was kann ich dagegen tun?
//Roger

[m-d-ley]

Hallo, ich habe das Problem, dass ich einige Werte aus einem Zähler nicht ausgelesen bekomme.
Es scheint alle Werte zu betreffen, welche über das M-Bus-Protokoll an das ModbusTCP-Gateway mit Dezimalkomma übertragen werden. Das Log eines Registers sieht folgendermaßen aus:

Code Auswählen Erweitern

2023.06.29 12:45:55 4: Test: GetUpdate (V4.5.5 - 9.5.2023) called from ControlSet
2023.06.29 12:45:55 5: Test: CreateUpdateHash full object list: h1560
2023.06.29 12:45:55 5: Test: CreateUpdateHash will request h1560 len 4 l1_volts_unscaled_UV100_V2
2023.06.29 12:45:55 4: Test: CombineUpdateHash objHash keys before combine: h1560
2023.06.29 12:45:55 5: Test: CombineUpdateHash tries to combine read commands
2023.06.29 12:45:55 5: Test: CombineUpdateHash keys are now h1560
2023.06.29 12:45:55 4: Test: GetUpdate will now create requests for h1560 len 4 (l1_volts_unscaled_UV100_V2)
2023.06.29 12:45:55 4: Test: DoRequest called from GetUpdate created new request, read buffer empty,
request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4)
2023.06.29 12:45:55 5: Test: QueueRequest called from DoRequest with h1560, qlen 0 from master Test through io device Test
2023.06.29 12:45:55 5: Test: StartQueueTimer called from QueueRequest sets internal timer to process queue in 0.000 seconds
2023.06.29 12:45:55 5: Test: ProcessRequestQueue called from Fhem internal timer as queue:Test, qlen 1, request: request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4), queued 0.00 secs ago
2023.06.29 12:45:55 5: Test: checkDelays sendDelay, last send to same device was 57.226 secs ago, required delay is 0.1
2023.06.29 12:45:55 5: Test: checkDelays commDelay, last communication with same device was 57.191 secs ago, required delay is 0.1
2023.06.29 12:45:55 5: Test: checkDelays clientSwitchDelay is not relevant
2023.06.29 12:45:55 5: Test: checkDelays busDelayRead is not required
2023.06.29 12:45:55 4: Test: ProcessRequestQueue (V4.5.5 - 9.5.2023) qlen 1, sending 0044000000060a0306180004 via 172.21.96.60:502, read buffer empty,
request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4), queued 0.00 secs ago
2023.06.29 12:45:55 5: Test: Send called from ProcessRequestQueue
2023.06.29 12:45:55 5: DevIo_SimpleWrite Test: 0044000000060a0306180004
2023.06.29 12:45:55 5: Test: readFn buffer: 00440000000b0a03080000000000000000 mode master, expect response
2023.06.29 12:45:55 5: Test: ParseFrameStart called from ReadFn protocol TCP expecting id 10
2023.06.29 12:45:55 4: Test: ParseFrameStart (TCP, master) extracted id 10, fCode 3, tid 68, dlen 11 and potential data 080000000000000000
2023.06.29 12:45:55 5: Test: HandleResponse called from ReadFn
2023.06.29 12:45:55 5: Test: HandleResponse is now creating response hash, masterHash is HASH(0x55cb0caac600)
2023.06.29 12:45:55 5: Test: HandleResponse is now calling ParseResponse, masterHash is HASH(0x55cb0caac600)
2023.06.29 12:45:55 5: Test: ParseResponse called from HandleResponse, fc 3
2023.06.29 12:45:55 5: Test: now parsing response data objects, master is Test relay is undefined
2023.06.29 12:45:55 5: Test: ParseDataString called from HandleResponse with data hex 0000000000000000, type h, adr 1560, op read
2023.06.29 12:45:55 5: Test: SplitDataString called from ParseDataString with data hex 0000000000000000, type h, adr 1560, valuesLen 4, op read
2023.06.29 12:45:55 5: Test: CreateDataObjects called from ParseDataString with objList h1560
2023.06.29 12:45:55 5: Test: CreateDataObjects sortedList h1560
2023.06.29 12:45:55 5: Test: CreateParseInfoCache called
2023.06.29 12:45:55 5: Test: CreateDataObjects unpacked 0000000000000000 with q> to 0
2023.06.29 12:45:55 4: Test: CreateDataObjects assigns value 0 to l1_volts_unscaled_UV100_V2
2023.06.29 12:45:55 5: Test: ParseDataString created 1 readings, errcode undef
2023.06.29 12:45:55 4: Test: HandleResponse done, current frame / read buffer: 00440000000b0a03080000000000000000, id 10, fCode 3, tid 68,
request: id 10, read fc 3 h1560, len 4, tid 68, master device Test, reading l1_volts_unscaled_UV100_V2 (getUpdate for l1_volts_unscaled_UV100_V2 len 4), queued 0.02 secs ago, sent 0.02 secs ago,
response: id 10, fc 3, h1560, len 4, values 0000000000000000
2023.06.29 12:45:55 5: Test: ResetExpect for HandleResponse from response to idle
2023.06.29 12:45:55 5: Test: DropFrame called from ReadFn - drop 00440000000b0a03080000000000000000
2023.06.29 12:45:55 5: Test: readFn end buffer:  mode master, expect idle

Habt ihr einen Tip?

[StefanStrobel]

Hallo Roger,

gleicher Fehler wie beim letzten Mal. Die utils müssen auch aktualisiert werden. Ich hab sie zusammen mit einem Update von HTTPMOD jetzt auch eingecheckt.

Gruss
   Stefan