Jump to content

duaw

Members
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    132

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    2

 Inhaltstyp 

Posts erstellt von duaw

    Wasserwarnung ... mit TF

    in Allgemeine Diskussionen

    Geschrieben

    Ja, Batti, das klingt gut. 

    Ich gehe gerne zu Fuß! Ich habe in der Nähe vom Einsatzort im Keller schon einen Stapel zum Überwachen/Steuern der Zu-/Abluft, am Stack ist noch ein Steckplatz frei. Mit nem langen Bricklet-Kabel könnte das was werden. Dann einklinken in MQTT und NodeRED, fertig ist es! 

    @DoIT: Das Wasser kam von außen rein über die Zu-/Abluft. Die Entwässerung derselben (im Sommer gibt es da Kondenswasser, jetzt war alles so draußen gesättigt, dass das Regenwasser im Boden seinen Weg da in die Zuluft hinein fand) in das Abwasser hatte ein – wirklich zweckfreies – Sieb, das sich zugesetzt hatte. Abschalten muss ich da nix. 

    Wäre grundsätzlich natürlich bei Waschmaschinen etc. sinnvoll. Hmm, ich kenne niemanden, dem die ausgelaufen ist.  

    Gruß, Uwe

    Wasserwarnung ... mit TF

    in Allgemeine Diskussionen

    Geschrieben

    Hallo, zusammen,

    nachdem es viel Wasser von oben und eine Verstopfung im Abfluss nach unten gab, stand das Wasser im Keller. Blöd. (Freundlicherweise war es klares Wasser, dass seinen Weg gefunden hatte, keine braune Brühe ... )

    Wie würde man einen Wasserstandswarner mit TF realisieren? Mit welchem Bricklet (und ggf. Zusatz-HW) könnte man auf welche Art & Weise stehendes Wasser >1mm auf dem Boden feststellen und so die Basis für eine Wasserwarnung realisieren? 

    Gruß, Uwe

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    vor 16 Stunden schrieb sihui:

    Ich habe einen anderen Weg gewählt um endlich auf openHAB3 umsteigen zu können: ich habe meine komplette Tinkerforge Hardware gegen andere Hardware getauscht.

    Hallo!

    Ich werde openHAB den Rücken kehren und auf NodeRed umsteigen. Ich habe mal mit OH1 angefangen, die Lösung dann mit OH2  betrieben. OH2 und OH3 gefällt mir einfach nicht mehr.

    NodeRed passt bei mir persönlich besser. Und meine Bedürfnisse bzgl. TF werden bestens mit den MQTT-Bindings erfüllt. Da muss ich nichts neues kaufen ... 

    Gruß, Uwe 

    Node-Red Tinkerforge Palette

    in Software, Programmierung und externe Tools

    Geschrieben

    Alles befolgt unter https://www.tinkerforge.com/de/doc/Software/APT_Repository.html#apt-repository ? 

    brickd läuft ? 

    systemctl status brickd liefert bei mir 

    ● brickd.service - Brick Daemon

       Loaded: loaded (/lib/systemd/system/brickd.service; enabled; vendor preset: enabled)

       Active: active (running) since Mon 2020-08-10 08:27:30 CEST; 7h ago

      Process: 460 ExecStart=/usr/bin/brickd --daemon (code=exited, status=0/SUCCESS)

    Main PID: 471 (brickd)

        Tasks: 7 (limit: 2068)

       CGroup: /system.slice/brickd.service

               └─471 /usr/bin/brickd --daemon

    Ach ja: Raspi aktuell ? sudo apt update // sudo apt upgrade durchgeführt?

    Gruß, Uwe ... jetzt weg.

     

     

     

    Node-Red Tinkerforge Palette

    in Software, Programmierung und externe Tools

    Geschrieben · bearbeitet von duaw

    Hallo, Philipp,

    leider habe ich das outdoor_weather_bricklet nicht. Um auszuschließen, dass das ein Bug im Bindung (in getstation_data) ist, sollte get_identity funktionieren. Das können ja alle Bricklets. 

    Hier mein Setup:

    • Mac (mit brickd und Brickv) und Raspi mit IP 192.168.1.200.Natürlich kann ich den Raspi vom Mac aus im Netz erreichen.
    • Unter MQTT.fx auf dem Mac habe ich ein  Connection Profile zum Broker  192.168.1.200 erstellt. 
    • Ich habe testweise ein humidity_v2_bricklet mit UID Dkd am Raspi am HAT Zero und 
    • einen Master mit temperature_bricklet mit UID zkv am USB des Raspi. 

    Auf dem Raspi  läuft  

    • der MQTT-Broker (Test: vom Mac aus kann ich mich mit MQTT.fx mit diesem verbinden, ich subscribe "#"  und publishe  "Blabla", dann wird "Blabla" am Mac wieder empfangen)
    • der brickd (Test: vom Mac aus kann ich mich mit dem BrickV mit 192.168.1.200:4223 verbinden. Ich sehe am Mac das HAT Zero und den Master mit allen Bricklets)
    • der tinkerforge_mqtt-Service (installiert mit sudo apt install tinkerforge-mqtt)

    Mein Test des Service, Schritt für Schritt:

    • Start MQTT.fx auf dem Mac
    • Connect vom Mac mit Broker auf Raspi (192.168.1.200) . Ich ordne Subscribe/Publish von MQTT.fx an, damit ich schöne beides im Blick habe.
    • subscribe # (alles) 
    • publishe vom Mac tinkerforge/request/humidity_v2_bricklet/Dkd/get_identity
    • erhalte die Antwort {"connected_uid": "QeK", "uid": "Dkd", "device_identifier": "humidity_v2_bricklet", "hardware_version": [1, 0, 0], "position": "b", "firmware_version": [2, 0, 6], "_display_name": "Humidity Bricklet 2.0"}
    • publishe vom Mac tinkerforge/request/temperature_bricklet/zkv/get_identity
    • erhalte die Antwort {"connected_uid": "62eUJm", "uid": "zkv", "device_identifier": "temperature_bricklet", "hardware_version": [1, 1, 0], "position": "c", "firmware_version": [2, 0, 4], "_display_name": "Temperature Bricklet"}

    Wenn Du ein anderes Bricklet hast, dann teste das auch mal.

    Wenn der Fehler bleibt, dann ... 🤨

    Gruß, Uwe

    PS Ich hoffe, dass klappt. Bin erst am Freitag wieder da.

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    MEA CULPA ... 

    1. Never touch a running system stimmt nicht immer! 

    2. Gib' Acht, wo welche Datei liegt !!! (Und lösche, was Du nicht mehr brauchst ... ) 

    python3 /usr/local/bin/tinkerforge_mqtt

    Und: Ja, die Ausgabe ist  

    2020-08-06 20:00:54,768 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet.
2020-08-06 20:00:54,772 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet succedded.
2020-08-06 20:00:54,772 <DEBUG> MQTT bindings: Publishing response to tinkerforge/111/response/temperature_bricklet/aK1/get_temperature
2020-08-06 20:00:54,772 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m8), 'b'tinkerforge/111/response/temperature_bricklet/aK1/get_temperature'', ... (21 bytes)
2020-08-06 20:00:54,772 <DEBUG> MQTT bindings:

    mit der letzten Leerzeile.

    So geht's!

    Danke! 

    Uwe

    Node-Red Tinkerforge Palette

    in Software, Programmierung und externe Tools

    Geschrieben

    Hallo, Philipp,

    das im Video sieht alles ganz vernünftig aus. Ich bin den Weg mit der Anleitung von TF gegangen. Die ist doch ganz gut! Leider habe ich keine ausführlichere step-by-step-Anleitung ... 

    VOR dem automatischen Ausführen als Service oder über crontab solltest Du manuell checken, ob die Einzelteile funktionieren. Und dabei "unten" anfangen.

    Wie ist Dein Aufbau? 

    Welche HW verwendest Du? Welches OS?

    Aktuelle SW?

    Wo läuft der MQTT-Broker? Läuft der? Kannst Du mit MQTT.fx überhaupt Nachrichten publishen/subscriben ?

    Wo ist welches Bricklet wie angeschlossen? Siehst Du das im BrickViewer?

    Hast Du python wie erforderlich ?

    Wo läuft das Bindung tinkerforge_mqtt?  Wie rufst Du das auf (nimm man --debug mit in den Aufruf 😉) Kannst Du das Binding in einer Shell (Konsole) aufrufen?

    Was funktioniert und was funktioniert nicht?

    Die Anleitung von TF ist doch ganz gut! Leider habe ich keine ausführlichere step-by-step-Anleitung ... 

    Gruß, Uwe

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    Hallo!

    Ich frage alle 30sec zyklisch ab. Das sollte doch unkritisch sein, oder?

    Ich habe das gerade nachgestellt (auf meinem Mac, habe Node-RED-Flow in der Zeit deaktiviert:  

    python3 tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 --global-topic-prefix tinkerforge/111 --debug

    Request: 

    2020-08-06 17:05:37,639 <DEBUG> MQTT bindings: Configuring connection to MQTT broker at 192.168.1.18:1883

2020-08-06 17:05:37,639 <DEBUG> MQTT bindings: Connected to MQTT broker at 192.168.1.18:1883

2020-08-06 17:05:37,646 <DEBUG> paho.mqtt.client: Sending CONNECT (u0, p0, wr0, wq0, wf1, c1, k60) client_id=b''

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Received CONNACK (0, 0)

2020-08-06 17:05:37,647 <DEBUG> MQTT bindings: Connected to mqtt broker.

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending SUBSCRIBE (d0, m1) [(b'tinkerforge/111/request/#', 0)]

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending SUBSCRIBE (d0, m2) [(b'tinkerforge/111/register/#', 0)]

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m3), 'b'tinkerforge/111/callback/bindings/restart'', ... (4 bytes)

2020-08-06 17:05:37,647 <DEBUG> paho.mqtt.client: Sending SUBSCRIBE (d0, m4) [(b'tinkerforge/111/callback/bindings/restart', 0)]

2020-08-06 17:05:37,648 <DEBUG> MQTT bindings: Connecting to brickd at 192.168.1.111:4223

2020-08-06 17:05:37,648 <DEBUG> paho.mqtt.client: Received SUBACK

2020-08-06 17:05:37,649 <DEBUG> paho.mqtt.client: Received SUBACK

2020-08-06 17:05:37,649 <DEBUG> paho.mqtt.client: Received SUBACK

2020-08-06 17:05:37,651 <DEBUG> MQTT bindings: Connected to Brick Daemon: Connection established after request from user.

2020-08-06 17:05:37,652 <DEBUG> MQTT bindings: Connected to brickd at 192.168.1.111:4223

2020-08-06 17:05:49,496 <DEBUG> paho.mqtt.client: Received PUBLISH (d0, q0, r0, m0), 'tinkerforge/111/request/temperature_bricklet/aK1/get_temperature', ...  (0 bytes)

2020-08-06 17:05:49,497 <DEBUG> MQTT bindings:



2020-08-06 17:05:49,497 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet.

2020-08-06 17:05:49,503 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet succedded.

2020-08-06 17:05:49,503 <DEBUG> MQTT bindings: Publishing response to tinkerforge/111/response/temperature_bricklet/aK1/get_temperature

2020-08-06 17:05:49,504 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m5), 'b'tinkerforge/111/response/temperature_bricklet/aK1/get_temperature'', ... (21 bytes)

2020-08-06 17:05:49,504 <DEBUG> MQTT bindings:

     

    Alles Gut. 😀 

    2020-08-06 17:06:49,747 <DEBUG> paho.mqtt.client: Sending PINGREQ

2020-08-06 17:06:49,748 <DEBUG> paho.mqtt.client: Received PINGRESP

    Reset im Brickviewer. Das folgende passiert dann manchmal 

    2020-08-06 17:07:47,960 <DEBUG> MQTT bindings: Device available: 6kN4to at 0 (Pos 0), Hardware: 2.1.0, Firmware: 2.4.10, Dev ID: 13

Exception in thread Callback-Processor:

Traceback (most recent call last):

  File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 926, in _bootstrap_inner

    self.run()

  File "/usr/local/Cellar/python/3.7.7/Frameworks/Python.framework/Versions/3.7/lib/python3.7/threading.py", line 870, in run

    self._target(*self._args, **self._kwargs)

  File "tinkerforge_mqtt", line 1470, in callback_loop

    self.dispatch_packet(data)

  File "tinkerforge_mqtt", line 1363, in dispatch_packet

    firmware_version, device_identifier, enumeration_type)

  File "tinkerforge_mqtt", line 7123, in <lambda>

    self.ipcon.register_callback(IPConnection.CALLBACK_ENUMERATE, lambda *args: self.ip_connection_callback_fn(IPConnection.CALLBACK_ENUMERATE, *args))

  File "tinkerforge_mqtt", line 7208, in ip_connection_callback_fn

    d["_display_name"] = display_names[dev_id]

NameError: name 'display_names' is not defined

    (Das ist aber wohl nicht kriegsentscheidend)

    Jetzt wieder ein Request: 

    2020-08-06 17:09:14,327 <DEBUG> paho.mqtt.client: Received PUBLISH (d0, q0, r0, m0), 'tinkerforge/111/request/temperature_bricklet/aK1/get_temperature', ...  (0 bytes)

2020-08-06 17:09:14,327 <DEBUG> MQTT bindings:

    Nicht mehr gut: 😒 

    2020-08-06 17:09:14,327 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet.

2020-08-06 17:09:14,327 <ERROR> MQTT bindings: Not connected (call of get_temperature of temperature_bricklet aK1)

2020-08-06 17:09:14,327 <DEBUG> MQTT bindings: Calling function get_temperature for device aK1 of type temperature_bricklet succedded.

2020-08-06 17:09:14,328 <DEBUG> MQTT bindings: Publishing response to tinkerforge/111/response/temperature_bricklet/aK1/get_temperature

2020-08-06 17:09:14,328 <DEBUG> paho.mqtt.client: Sending PUBLISH (d0, q0, r0, m6), 'b'tinkerforge/111/response/temperature_bricklet/aK1/get_temperature'', ... (127 bytes)

2020-08-06 17:09:14,328 <DEBUG> MQTT bindings:

    Die Message ist 

    {"temperature": "{\"temperature\": null, \"_ERROR\": \"Not connected (call of get_temperature of temperature_bricklet aK1)\"}"}

    Beenden des Bindings, Neustart, wieder alles gut. 

    Hilft das?

    Gruß, Uwe

     

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    Hallo,

    mein altes Temperature-Bricklet liefert ja auch gelegentlich falsche Werte. Es ist via TF-MQTT-Service angeschlossen, der wie in der Doku beschrieben das MQTT-Binding bereitstellt.. 

    In Node-Red erkenne ich das, dann resette ich dem Master in Node-Red per exec-Node. 

    Leider muss ich dann den TF-MQTT-Service für diesen Stapel (eigene IP) neu starten. (Was ich jetzt erst mal noch manuell mache , aber das geht sicher auch via Node-Red ). 

    Ein ganz "normaler" Reset des Masters parallel aus dem brickv bringt den Service/das Bindung auch aus dem Tritt. Nicht aber einen parallel laufenden anderen brickv. 

    Warum ist das so?

    Gruß, Uwe

     

    Überwinterung von Pflanzen

    in Allgemeine Diskussionen

    Geschrieben

    Hallo!

    Der Winter wird kommen und damit die Überwinterung von Pflanzen im (isolierten) Gartenhaus. Dazu möchte ich einen elektrischen Heizlüfter (500W), 2x RGB-Pflanzenlicht (à 50 W)  und einen kleinen Bad-Lüfter (wenn es zu feucht/warm wird) schalten (mit MQTT/Node-Red auf Raspi [ist vorhanden] lokal in der Gartehütte). 

    Das Licht ginge wie bisher auch über eine Zeitschaltuhr. Aber der "Frostwächter" ist zu aggressiv: Es darf ruhig unter 5°C kalt werden. Und beim Lüften möchte ich etwas Intelligenz einbauen. Die Außentemperatur kommt via MQTT/Netzwerk von aussen. Die Regelung muss aber lokal und stabil sein, weil die Netzwerkverbindung per Powerline hin und wieder kollabiert.

    Ich oute mich mal als elektrischer Dilettant: Wie geht das  am besten? ("Gut" besitzt leider ganz verschiedene Aspekte: Betriebssicherheit, Kosten, Security, Lebensdauer ...)  

    Mit TF : Sollte ich  Funksteckdosen und Remote Switch 2.0 (alles vorhanden) nehmen? Da würde EIN Bricklet ja für alle 3 Funksteckdosen reichen. Ist das wohl zuverlässig? 

    Mit TF: Oder doch Industrial Dual Relay Bricklet? Habe ja auf dem Zero HAT Brick nur 4 Ports (HAT Brick nicht lieferbar!)

    Oder ohne TF: MQTT und dann LAN oder WLAN-Schalter (z.B. Sonoff) ? Wie zuverlässig ist das? 

    Welche Lösungen verwendet ihr?

    Gruß, Uwe

     

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    Am 6.5.2020 um 10:44 schrieb rtrbt:

     

    Der Aufruf sieht korrekt aus, probiere danach mal sicherheitshalber folgendes: 

    
uint8_t mode;
barometer_get_i2c_mode(bl_baro, &mode);
printf("i2c mode %s\n", mode == BAROMETER_I2C_MODE_FAST ? "BAROMETER_I2C_MODE_FAST" : "BAROMETER_I2C_MODE_SLOW");

    (Achtung, ungetesteter Code!)

    Hallo!

    Die aktuellen C/C++-Bindings wurden am 7.4. generiert. Die i2c-Funktionen sind in bricklet_barometer.c/.h noch nicht deklariert/definiert . Die Funktionen der Firmware 2.0.3. vom 5.5. können nicht in C/C++ aufgerufen werden. (Es wurden seitdem nur die MQTT-Bindungs upgedatet, oder?)  

    Gruß, Uwe

     

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben · bearbeitet von duaw

    Nein, --ipcon-timeout 10000 hat nicht geholfen. Das dauert auch weniger als 2,5 Sekunden ... 

    Nein, das Problem liegt vielmehr ganz woanders: Ich habe mehrere Stapel mit Ethernet-Extensions im Einsatz. Ich lasse also für jede IP-Adresse eine Instanz des MQTT-API-Binding laufen. Muss ich ja, da ich dem Binding genau EINEN ipcon-host nennen kann. Also:

    tinkerforge_mqtt  mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.111 
    tinkerforge_mqtt_112 mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.112 
    ...
    tinkerforge_mqtt_115 mit der Zeile ExecStart=/usr/bin/python /usr/local/bin/tinkerforge_mqtt --broker-host 192.168.1.18 --ipcon-host 192.168.1.115  

    In Node-RED requeste ich per MQTT tinkerforge/request/temperature_bricklet/aK1/get_temperature . Das Bricklet ist am Stapel mit der IP 192.168.1.111

    ALLE 5 laufenden services erhalten die Nachricht, fühlen sich dann also angesprochen, aber nur einem service gelingt es, die Temperatur zu liefern (dem, der an ipcon-host 111 horcht), die 4 anderen versuchen es und geben dann auf.

    Es kommt also 1 mal die Temperatur und 4 mal die Fehlermeldung. 

    Hmmm ... Möglichkeiten:  

    • Ich werde versuchen, das mit dem --global-topic-prefix-Parameter irgendwie hinzubasteln. Da steht in der Doku Der Präfix kann beispielsweise verwendet werden, um mehrere Binding-Instanzen, die mit dem selben Broker verbunden sind, zu trennen. Dann muss ich selbst drum kümmern ... 

    Alternativ:   

    1. tinkerforge_mqtt "wird Multi-ipcon-host"-fähig und bekommt beim Aufruf eine Liste von --ipcon-hosts (Nein.) 
    2. tinkerforge_mqtt findet heraus, dass das Bricklet vom gewünschten Typ mit der UID nicht da ist und ignoriert den Aufruf (Eher unwahrscheinlich)
    3. tinkerforge_mqtt hat eine Option, mit der auf die "Antwort" verzichtet wird. (Warum nicht. Ich kann/muss mich eh' drum kümmern. Ob sie nun nicht gekommen ist oder als Nachricht, dass sie nicht kam ist mir egal)
    4. die IP-Adresse wird Bestandteil von payload oder topic  

    Gruß, Uwe

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    Am 28.4.2020 um 13:26 schrieb rtrbt:

    Zu deinem Timeout-Problem: Die Meldung kommt von den MQTT-Bindings. Der Timeout (der übrigens eigentlich konfigurierbar sein sollte, habe ich mir mal auf die TODO-Liste gesetzt) sollte auf den standardmäßigen 2,5 Sekunden stehen. Das ist etwas unerwartet, dass bei deinem Aufbau (da ist jetzt nichts Traffic-intensives dabei) regelmäßig Timeouts kommen (was heißt übrigens regelmäßig? Einmal pro Minute/Stunde/Tag?) aber an sich kann es schon passieren, dass mal ein Paket verloren geht.

    Mit schöner Regelmäßigkeit – alles 30 sec wird gepollt – kommt:  

    mosquitto_sub -t tinkerforge/response/temperature_bricklet/ziB/get_temperature -h 192.168.1.18
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": 1756}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": 1756}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}
{"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet ziB)\"}"}

    Erst ein Timeout, dann der Wert, dann 3x Timeout ... 30 sec Pause … dann Timeout, dann der Wert, dann 3x Timeout.

    Hmmm. Muss noch mal checken, ob da Node-RED mehrere Abfragen feuert ... 

    Gruß, Uwe

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben · bearbeitet von duaw

    Ich habe Temperature / Humidity / Barometer / Dual Relay und nehme die Temperatur aus ... Temperature. Das Bricklet zeigte -38,43°C. 

    Dual Relay schaltet die Luftzufuhr ins Haus zwischen "lang" und "kurz" . Habe da ein Eltako 1393097 dazwischen, weil das Schalten via Dual Relay nur so zuverlässig ging. Beim Ausfall der Temperatur vorhin wurde aber nicht geschaltet.

    Ich habe noch openHAB 2.4 am Laufen mit dem alten Binding von Theo. Habe irgendwie Angst vor der Migration ... solange das "Beta", die Doku unvollständig ist und der Einarbeitungsaufwand irgendwie nicht überschaubar erscheint. Never touch a running system . Und wie gesagt: Node-RED ist ganz nett! (mit oH ist es aber einfacher, gut aussehende Resultate zu erzielen ...) 

    ------

    Eher ein Thema für einen neuen Thread: Wo liegen die Nachteile / Vorteile oH-nativ vs. oH-MQTT ? In Node-RED kommt ja alles via MQTT an (Für jeden Stapel mit eigener IP-Adresse starte ich einen eigenen Service.) Das ginge ja auch in oH. Mir gefällt Deine MQTT-Lösung sehr gut! Warum sollte ich das TF-oH-Bindung benutzen? 

    (Noch 'ne Frage, definitiv etwas off-topic: Noch rufe ich in Node-RED MQTT request auf. Das ist nicht zeitkritisch. Regelmäßig kommt auch {"temperature": "{\"temperature\": null, \"_ERROR\": \"Did not receive response for function 1 in time (call of get_temperature of temperature_bricklet aK1)\"}"} Das ignoriere ich. Dann kommt wieder {"temperature": 1556} .  Die Verbindung via BrickV steht. Woran kann das liegen? Irgendwo ein zu aggressives Timing im MQTT-service-API? Stapel ist im Aussenbereich via Powerline angeschlossen. )

    Gruß, Uwe

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    Hallo!

    Schwups, es ist wieder passiert. Eben 6:42 Uhr. Beobachtung: (Habe noch keine Regel) Reset aus dem Brickviewer, kurz die 10°, dann wieder -38,4; noch ein Reset, dann dann ok ... 

    Es war der Aufbau mit dem Barometer / Humidity / Dual Relay / PoE, aber es gab keinen Schaltvorgang im Garten. EMI dort?. 

    Da ist noch openHAB mit dem alten TF-Binding im Einsatz. Parallel wechsle ich langsam auf Node-RED/MQTT, noch mit periodischer 30sec-Abfrage. Mit MQTT kann ich auch den i2c-Modus setzen. 

    Gruß, Uwe

     

    Temperatur und Luftdruck liefern plötzlich falsche Werte

    in Hardware

    Geschrieben

    Hallo, André,

    ich habe im überdachten Aussenbereich (!) einen Stapel mit Temp / Bar / Hum / Dual Relay  / PoE (ich meine, das läuft stabil) zum Regeln der Luftzufuhr / Messen. Und dann in einer Hütte wieder via Powerline zur Überwinterung Hum / 2x Temp (unten, oben) / Hum mit Ethernet (nicht PoE) und Steckernetzteil. Ich meine, das ist der Kandidat. 

    Sporadisch: Dieses Jahr noch nicht. Letztes Jahr im Sommer ? 1 mal ? Davor länger nicht ? Ich glaube sogar, ich musste den Stapel stromlos machen, weiss das aber nicht mehr genau. 

    So selten, dass ich es nicht genau weiß, aber so häufig, dass ich die Überwinterung noch nicht Node-RED bzw. openHAB anvertraue. Hatte auch immer mal Powerline-Probleme (und die SW läuft auf einem Rechner im Haus!), da zweifle ich an der Zuverlässigkeit. Werde die Überwinterung vor Ort steuern (mit Backup ... )

    Gruß, Uwe

     

×
×
  • Neu erstellen...