piwo2

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