
piwo2
Members-
Content Count
7 -
Joined
-
Last visited
Community Reputation
0 Neutral-
ok. kleine frage : warum wird dann der request des callbacks des bricklets honoriert (d.h. callback-responses treten erneut auf) ? "Überlebt" der callback des temperature bricklets (und die bricklet-callbacks antworten wieder weil noch aktiv oder wieder aktiviert oder noch nicht deaktiviert) oder wird nur der enumerate-callback quasi "vergessen" ? (edit:) ok. es wurde nur der enumerate-request nicht erneut abgesetzt, und ein erneutes enumerate beim start der bindings fehlt dann .... aber soweit ich gesehen habe erfolgt doch ein enumerate beim start der bindings ...
-
bumpup kein bug ? feature ? lg wp
-
--init-file { "pre_connect": { "tinkerforge/register/ip_connection/connected": {"register": true}, "tinkerforge/register/ip_connection/disconnected": {"register": true}, "tinkerforge/register/ip_connection/enumerate": {"register": true} }, "post_connect": { "tinkerforge/request/ip_connection/enumerate": "", "tinkerforge/request/temperature_bricklet/siX/set_temperature_callback_period": {"period":10000}, "tinkerforge/register/temperature_bricklet/siX/temperature": {"register": true} } } SZENARIO1 : start tinkerforge_mqtt, st
-
!!!!!!!!!!!!! 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 einba
-
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,top
-
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 getr