Zwei Sachen:
- Der Knackpunkt liegt (in meiner Version) in der Schleife die STX prüft. Der kritische Zeitraum liegt zwischen dem Empfang der ID und dem senden des ACKs. Hatte ja schon erwähnt dass ein Zähler ohne ACK z.B. gar nichts macht - da bringt auch eine feste Baudrate nichts ... das muss 100% passen.
- Die Initialisierung des Ports in der self._update_values brachte folgenden Vorteil an den ich mich jetzt gerade erinnere- mea culpa. War der Port bei __init__ intitalisiert erhielten wir ja nur beim ersten Durchlauf die ID. Bei den folgenden wurde vor der ID noch ein /x07 (BEL) mit ausgegeben, damit fiel dann sowohl bei der Echo-Unterdückung als auch bei der Baudrate alles auf die Nase. Komischerweise taucht das hier jetzt nicht auf, aber wer kann das erklären? Grundsätzlich machen wir doch das gleiche.
Code:
2013-11-26 17:25:05,253 DEBUG DLMS dlms: update -- __init__.py:_update_values:55 2013-11-26 17:25:05,755 DEBUG Scheduler DLMS next time: 2013-11-26 17:25:20+01:00 -- scheduler.py:_next_time:289 b'/' b'/L' b'/LG' b'/LGZ' b'/LGZ4' b'/LGZ4Z' b'/LGZ4ZM' b'/LGZ4ZMF' b'/LGZ4ZMF1' b'/LGZ4ZMF10' b'/LGZ4ZMF100' b'/LGZ4ZMF100A' b'/LGZ4ZMF100AC' b'/LGZ4ZMF100AC.' b'/LGZ4ZMF100AC.M' b'/LGZ4ZMF100AC.M2' b'/LGZ4ZMF100AC.M23' b'/LGZ4ZMF100AC.M23\r' 2013-11-26 17:25:06,353 DEBUG DLMS dlms: meter returned capability for higher baudrate - will request 4800 baud -- __init__.py:_update_values:81 2013-11-26 17:25:06,355 DEBUG DLMS dlms: trying to switch to 4800 baud -- __init__.py:_update_values:95 b'' 2013-11-26 17:25:08,358 DEBUG DLMS dlms: reading took: 3.10s -- __init__.py:_update_values:110 2013-11-26 17:25:20,289 DEBUG DLMS dlms: update -- __init__.py:_update_values:55 b'/' b'/L' b'/LG' 2013-11-26 17:25:20,790 DEBUG Scheduler DLMS next time: 2013-11-26 17:25:35+01:00 -- scheduler.py:_next_time:289 b'/LGZ' b'/LGZ4' b'/LGZ4Z' b'/LGZ4ZM' b'/LGZ4ZMF' b'/LGZ4ZMF1' b'/LGZ4ZMF10' b'/LGZ4ZMF100' b'/LGZ4ZMF100A' b'/LGZ4ZMF100AC' b'/LGZ4ZMF100AC.' b'/LGZ4ZMF100AC.M' b'/LGZ4ZMF100AC.M2' b'/LGZ4ZMF100AC.M23' b'/LGZ4ZMF100AC.M23\r' 2013-11-26 17:25:21,309 DEBUG DLMS dlms: meter returned capability for higher baudrate - will request 4800 baud -- __init__.py:_update_values:81 2013-11-26 17:25:21,311 DEBUG DLMS dlms: trying to switch to 4800 baud -- __init__.py:_update_values:95 b'' 2013-11-26 17:25:23,316 DEBUG DLMS dlms: reading took: 3.03s -- __init__.py:_update_values:110 ^C2013-11-26 17:25:25,774 INFO Main Number of Threads: 7 -- smarthome.py:stop:348 2013-11-26 17:25:25,775 INFO Main Stop Plugins -- plugin.py:stop:70 2013-11-26 17:25:26,318 INFO Main SmartHome.py stopped -- smarthome.py:stop:372
Ein anderes Phänomen, vielleicht nicht ganz offtopic und hilft die Sache zu verstehen. Ich hatte das Roomba-Plugin ja auch erst auf serieller Basis und dann auf Sockets umgestellt in der Hoffnung dass ein close dort besser wirkt. Der Roomba hängt an einem Bluetooth Modul und ich wollte da nur Saft rausziehen wenn tatsächlich kommuniziert wird. Wenn ich ein python script in der shell ausführe um die Werte auszulesen sehe ich wie das blinkende Modul auf dauerleuchtend geht und beim beenden des scriptes wieder blinkt. Beim Plugin jedoch bleibt die LED am Modul auf Dauerbetrieb, auch wenn ich close() und del mache (keine exceptions). Beende ich die sh.py Instanz fängt das Modul wieder zu blinken an, also sitzt da noch irgendwas drauf. Kann ein ähnliches Phänomen hier vorliegen?



Einen Kommentar schreiben: