piwo2

!!!!!!!!!!!!! grossartige nachricht !!!!!!!!!!!!!!! ich forsche schon seit wochen nach frameworks & deren möglichkeiten, anpassungen/workarounds in richtung tinkerforge UND andere (z.b. ebus, knx) unter einen hut zu bringen .... als einziger ansatz ist mir bisher seitens tf der mqtt-proxy via einer eigens zu schreibenden "übersetzungs-middleware" eingefallen .... eigene bindings würden nun openhab definitiv als integrationsschicht der ersten wahl anbieten ! bin echt gespannt & aufgeregt. endlich nägel mit köpfen. lg wp

hallo ! in meiner sichtwiese sind die bindings wie ein service für höherliegende applikationen ! das hat 2 konsequenzen : a) das service (bindings) muss theoretisch immer laufen. dazu müssen sie (bindings) : 1) gestartet und im a) nicht fatalen fehlerfall restartet werden bis ein retry-count oder timeout erreicht wird : diese aufgabe übernimmt im idealfall der systemd oder ein cron-job b) fatalen fehlerfall nicht mehr restartet werden c) muss ich diesen "systemzustand" entweder aus den mqtt-topics der bindings erkennen können oder separate topics im restart-script einbauen, die den zustand dieses "services" für übergeordnete applikationen widerspiegeln d) dazu muss idealerweise ein (re-)startscript ausreichend informationen von den topics bindings haben e) sollte eine (re-)startlogik aber in den bindings über "ihre" topics selbst verfügbar sein, bzw. der "systemzustand" auch dort ablesbar sein, so fällt eine externe überwachung über ein (re-)start-script natürlich weg ... die state-machine wäre idealerweise so ähnlich wie state=starting, ts_started=<now>, ts_now=<now> state=running, ts_started=<time of state == starting>, ts_now=<now> state=retrying, ts_started=..., ts_now=..., retry_count_now=..., time_between_retries=<cmd_line_parameter>, max_retry_count=<cmd_line_parameter> state=giveup, ts_started=..., ts_now=..., retry_count_now=<same as max_retry_count>, time_between_retries=<cmd_line_parameter>, max_retry_count=<cmd_line_parameter> ---- beantwortet das die frage ? nebenbei : warum wird für jeden internen zustand der bindings ein eigener topic mit inhalt "null" genutzt ? es wäre doch EIN topic mit entsprechdem inhalt ev. besser bzw. EIN topic für (re-)start und je EINER für jeden "internen zustand" einer dezidierten komponente : z.b. mqtt-status, brickd-status, _ERROR-status .... lg wp

danke vielmals ! werde das testen mal ... mqtt ist für mich das werkzeug derwahl, somit ziemlich zentral ;-) ============= noch ein paar gedanken ......... ich nutze folgedes pattern für - cronjob oder sonstige endloslogik in einem bash-skript : sub(topic=PREFIX/status) # falls "terminated" (mqtt-proxy abnormales ende) : # retry counter bzw. timeout ## mqtt-proxy start pub(qos=2,retained=true,topic="PREFIX/status",data="starting") - im gestarteten programm : connect(LWT=(qos=2,retained=true,topic="PREFIX/status",data="died")) ... pub(qos=2,retained=true,topic="PREFIX/status",data="started") sub(topic=PREFIX/status) pub(qos=2,retained=true,topic="PREFIX/status",data="functional") ... ... # exceptions triggern LWT und # sinnvolle statusinformationen werden gepublished : pub(qos=2,retained=true,topic="PREFIX/status",data="blah-whatever") ... ... if transient_error: pub(qos=2,retained=true,topic="PREFIX/status",data="restartable") disconnect() # LWT discard exit(1) if fatal_error: pub(qos=2,retained=true,topic="PREFIX/status",data="fatal") disconnect() # LWT discard exit(1) ... ... pub(qos=2,retained=true,topic="PREFIX/status",data="done") disconnect() # LWT discard exit(0) # reguläres programmende --- je nach programmstruktur sollte sich mit einem solchen pattern 1) nutzbare informationen für die restartlogik ergeben 2) eine verlässliche (quos=2 !!!) "interne" state-machine implementieren, die über on_message() nicht nur auf mehrfachen programmstart checkt, sondern auch sonst z.b. den *** "robusten ansatz" der tinkerforge-programme *** umsetzt ;-) ============= bottom line : bitte nochmals ein review, das die (externe) restartlogik in die überlegungen miteinbezieht und : wie wird der MQTT-proxy eigentlich von aussen "regulär beendet" ? SIGTERM ? ... er läuft ja idealerweise endlos ... und KeyboardInterrupt von extern triggern - da bin ich kein spezialist ;-) lg wp

hallo ! a) soweit ich der doku und den sourcen von "tinkerforge_mqtt" entnehme, ist es bereits jetzt möglich -> register/ip_connection/disconnected und -> register/ip_connection/connected vorzunehmen ... -> callback/ip_connection/connected wird am anfang aber explizit nie aufgerufen : stattdessen ist mit dem initialisierungs-file implizit die einzige möglichkeit gegeben, callbacks zu registrieren bzw. ein anfängliches enumerate anzustossen ... -> callback/ip_connection/disconnected ist aber z.zt. ebenfalls "seltsam" : soweit ich sehe, wird dieser callback nur getriggert, falls ein "regulärer" ausstieg via KeyboardInterrupt erfolgt. alle anderen umstände haben "seltsame" dinge zur folge : (PROBLEM ? BUG? falsch verstanden ?) wenn ich eine zwischenzeitliche ip-netzwerk-unterbrechung zum brickd simuliere, scheint der disconnect probe thread dies nicht zu erkennen ! selbst wenn ich abseits der zu erwartenden callbacks auch funktionen via -> request/.../get_identity o.ä. absetze, erhalte ich -> response/.../get_identity { '_ERROR' : "Did not receive response for function BLAH in time ..." } ... aber es erfolgt keinerlei triggern eines -> callback/ip_connection/disconnected !!! b) dieses momentane design macht es ausserordentlich mühsam, ein scheitern eines kompletten "stacks" aus erwarteten uid's konsistent zu managen : jeden topic auf { ..., "_ERROR" : ... } zu prüfen IST mühsam ! es könnte auch einen weiterer "höher" aggregierter topic z.b. -> callback/bindings/issue { "type" : ... } eingebaut werden, wo dann von aussen entschieden werden kann, ob es sich um ein potentiell temporäres problem der ip_connection handelt und das wartens auf ein reconnect sinnvoll ist oder eine - permanent fatale - exception auftrat ... aufgrund dieser info kann man noch immer entscheiden, ob man mittels z.b. -> request/bindings/terminate ein normales mqtt-disconnect durchführt oder über -> request/bindings/abort und den proxy ohne disconnect mit exit(1) beendet ... wenn -> callback/ip_connection/connected & -> callback/ip_connection/disconnected arbeiten wie es sein sollte (d.h. von anfang an und der disconnect prober funkt !!!), dann kann eine restartlogik über -> request/bindings/reset_callbacks & -> request/ip_connection/enumerate auch mühelos eingebaut werden ... wie gesagt : es müsste aber auch ein -> request/bindings/terminate beinhalten, wo durch einen sofortigen "normalen" disconnect vom mqtt-proxy ein benutzerdefinierter "last will" verhindert wird oder über -> request/bindings/abort mit exit(1) so wie bei fatalen fehlern den proxy einfach beendet und den "last will" triggert ... vorteile : sämtliche exceptions die NICHT AUSSCHLIESSLICH connection-bezogen sind und wo man (MIT TIMEOUT ;-) !!!) auf einen reconnect warten kann & sollte, aber auch fatale exceptions werden durch - eventuell von aussen angesteuerte - abnormale termination & benutzerdefinierten last will "von aussen" erkennbar ... --- ersuche um gedanken & ev. andere lösungsvorschläge ziel ist : sinnvolle behandlung von connection-issues auf höher aggregierter topic-ebene, die eine sinnvolle restartlogik erlauben oder eben ein GIVEUP und : der proxy soll ja auch für eine generelle integration tauglich sein, und nicht nur für fire & forget & warten auf godot ...