ElabNET Technik Forum

KFloo hat geschrieben: ↑Sa Okt 29, 2022 12:33 pm M.M.n. ist die Frage, warum der Input 1 im Bügelzimmer nicht True ist.

Ich glaube das ist nicht das Problem. Der Eingang wird im Screenshot vermutlich "noch" nicht als true dargestellt, weil die Logik seit dem Überschreiten der 62% noch nicht getriggert hatte. Die Logik triggert ja "nur" alle 5 Minuten.

Ich tippe immer mehr darauf, dass es das Minuszeichen vor den Schwellwerten der "Solarleistungseingängen" ist...die werden ja nach meinem Verständnis nie -600 oder -300 und somit ändern sich diese Eingänge aktuell nie auf true.

Hi,

ja, da hast du recht, dann müssten sich aber doch beide Bausteine gleich falsch verhalten - sie verhalten sich aber unterschiedlich, zumindest habe ich den TE so interpretiert.

Ich glaube hier, dass die "Solarleistungseingänge" nicht die Solarleistung ist, sondern der aktuelle Stromverbrauch des Hauses. Jetzt (im Screenshot) bezieht er gerade Strom aus dem Netz, also "+". Hat er einen Überschuss, wird der Bezug negativ.

Ich würde den Fehler im Ausschlussverfahren suchen. Mal die Eingänge deaktivieren und nach-und-nach hinzufügen und die Reaktion beobachten.

Viele Grüße!

KFloo hat geschrieben: ↑Sa Okt 29, 2022 1:09 pm sie verhalten sich aber unterschiedlich, zumindest habe ich den TE so interpretiert.

stimm, hast recht, so habe ich es eigentlich auch verstanden.

KFloo hat geschrieben: ↑Sa Okt 29, 2022 1:09 pm Ich glaube hier, dass die "Solarleistungseingänge" nicht die Solarleistung ist, sondern der aktuelle Stromverbrauch des Hauses. Jetzt (im Screenshot) bezieht er gerade Strom aus dem Netz, also "+". Hat er einen Überschuss, wird der Bezug negativ.

Ja, das ergbit Sinn...daran habe ich nicht gedacht. Dann sehe ich allerdings aktuell auch keinen Grund dafür, dass die Logik nicht macht, was sie soll.

Jetzt könnte es natürlich sein, dass dem TE auch nicht klar war dass die Schwellwert-Grenzen erst beim Triggern der Logik alle 180sek ausgewertet werden und er daher irrtümlich angenommen hat, dass die Logik nicht so agiert, wie gewünscht.

In diesem Fall wäre es denkbar alle Eingänge mit dem Eingangsverhalten C auszuführen und den Ausgang auf T, dann sendet. Dann wäre es leichter zu überblicken...aber die Logik würde auch wesentlich öfter "unnötig" abgearbeitet. Den TWS wird es nicht wirklich jucken...aber korrekte fände ich Logik so wie sie ist.

Man könnte das Ganze noch optimieren, in dem man Tiefpassfilter (also Glättungsfunktionen) einsetzt...aber dann würde man hier in diesem Beispiel mehrere Logiken oder eine Custom-Logik benötigen. Das halte ich hier aber erstmal für ein wenig überzogen.

Und dennoch...es wäre vermutlich als nächster Schritt gewünscht, dass ab irgendeiner Feuchtigkeitsüberschreitung (und dies insbesondere, wenn diese per Tiefpassfilter geglättet ist) so einzustellen, dass der Lüfter auch startet, wenn kein Solarstrom vorhanden ist. Quasi eine Eskalationsstufe, wenn mal viele Tage im Winter kein Solarertrag vorhanden ist aber der Keller feucht ist...

Robosoc hat geschrieben: ↑Sa Okt 29, 2022 11:56 am Sorry falls die Frage jetzt aus irgendeinem Grund überflüssig ist, aber für mich sieht es so aus, als würdest Du bei den Schwellwertschaltern kleiner minus 300 und kleiner minus 600 stehen haben. Ist das gewollt?

Mein Smartmeter liefert die Bilanz (Verbrauch - PV Erzeugung = Bezug; ist Erzeugung > Verbrauch dann wird der Bezug negativ) der Stromflüsse, daher ist alles was negativ ist eben Einspeisung (oder eben "übrig"). Es ist also schon korrekt so mit den negativen Werten und dem "kleiner als".

Cu
Frank

Robosoc hat geschrieben: ↑Sa Okt 29, 2022 1:23 pm Jetzt könnte es natürlich sein, dass dem TE auch nicht klar war dass die Schwellwert-Grenzen erst beim Triggern der Logik alle 180sek ausgewertet werden und er daher irrtümlich angenommen hat, dass die Logik nicht so agiert, wie gewünscht.

Um das nochmal klarer darzustellen: Ausschliesslich die Auswertung der Feuchte liefert bei den beiden Logiken unterschiedliche Werte. Alle anderen Objekte werden korrekt ausgewertet. Ebenso funktioniert die gesamte Logik im Vorratskeller sauber. Daher weiss ich jetzt zumindest, dass die Auswertung der Feuchte nur beim MQTT Device nicht korrekt funktioniert. Ich weiss nur noch nicht weshalb.

Der Sensor liefert ja Werte (siehe Screenshot), nur triggert der Eingang nicht auf TRUE, obwohl die Feuchte klar über der Schaltschwelle liegt (und, wie gesagt, im selben Szenario beim Vorratskeller bei Feuchte >62% das Objekt auch TRUE wird).

Hoffe das hat die Lage etwas klarer gemacht. Es geht mir einzig und alleine um die Frage, warum die beiden Feuchte-Objekte bei erfüllter Kondition einmal TRUE und einmal FALSE auswerten. Kann ich mir logisch einfach nicht erklären.

Cu
Frank

terseek hat geschrieben: ↑Sa Okt 29, 2022 12:18 pm Kann es sein, daß du die Eingänge 1 und 2 vertauscht hast?

Inwiefern ? PV Leistung und Feuchte sind bei den beiden Logiken jeweils anders belegt, ja, aber das war einfach Unachtsamkeit. Solange die verknüpften Objekte auf die passenden Filter gehen, ist das doch egal?

Cu
Frank

KFloo hat geschrieben: ↑Sa Okt 29, 2022 12:33 pm M.M.n. ist die Frage, warum der Input 1 im Bügelzimmer nicht True ist.

Korrekt, genau darum geht es.

KFloo hat geschrieben: ↑Sa Okt 29, 2022 12:33 pm Schau mal, ob du MQ1 als Float formatiert hast (mach doch auch mal nur testweise die Einheit % weg. Keine Ahnung, nicht dass 67.20% als 0.672 interpretiert wird, oder so...)

Wenn man sich die Werte des MQTT Objekts anschaut, dann kommen da korrekte Werte als Floats mit Einheit Prozent raus (Also 67,2% und nicht 0,672)

Cu
Frank

zaphood hat geschrieben: ↑Sa Okt 29, 2022 5:00 pm Der Sensor liefert ja Werte (siehe Screenshot), nur triggert der Eingang nicht auf TRUE, obwohl die Feuchte klar über der Schaltschwelle liegt (und, wie gesagt, im selben Szenario beim Vorratskeller bei Feuchte >62% das Objekt auch TRUE wird).

Erstelle mal bitte eine neue AND Logik-Zelle nur zum Test und lege darin nur einen Eingang mit Verhalten C an. Diesen verbinde bitte mit der MQTT Feuchte und stelle den Schwellwert wie in deiner Logik ein (oder so, dass du bei aktuellen Feuchtewerten ein true erwarten würdest. Dann speichern und Doktormodus an.

Das entspricht der Idee von kFloo mit dem Ausschlussverfahren , nur einfach mit einer eigenen Test-Logik.

Hallo zusammen!

Ich vermute ebenfalls, dass die Logik noch nicht getriggert wurde.

@Frank: Generell wäre in deinem Fall folgende Einstellung besser:
- alle Eingänge auf “a” oder “c”
- Ausgang auf “t”

Damit ist die Logikzelle intern immer aktuell und wird trotzdem nur alle 180s gesendet. Gerade in Kombination mit Eingangsfilter kann das sonst verwirrend sein und macht die Fehlersuche in der Regel viel einfacher.

Lg
Robert

Robert_Mini hat geschrieben: ↑So Okt 30, 2022 8:38 am @Frank: Generell wäre in deinem Fall folgende Einstellung besser:
- alle Eingänge auf “a” oder “c”
- Ausgang auf “t”

Hallo Robert,

ich habe gestern und heute folgendes getestet: Anstatt des MQTT Sensors einfach einen anderen KNX Sensor als Input für die Feuchte genommen -> geht wie erwartet, Logik funktioniert ohne jede weitere Änderung.

Dann habe ich den MQTT wieder genommen, den Eingang von "U" auf "A" gestellt, wie von dir vorgeschlagen -> Tut nun auch. (Ausgang kann dabei bleiben, muss nicht auf "T"). Danke für die Idee!

Mein Resumee daraus ist, dass der MQTT basierte Sensor als Eingang anders verarbeitet wird als der KNX. Beide senden alle 5 min, beide senden als Float, kann mir den Unterschied daher nicht erklären. Schon gar nicht verstehe ich, weshalb am Eingang "A" anstatt "U" den Interpretationsunterschied behebt (worin sich der auch immer begründet).

Im Sinne der "sauberen" Logik habe ich dann am Ende der Tests bei beiden Logiken die Ein- und Ausgänge wie von dir vorgeschlagen noch angepasst (hat aber nichts am Ergebnis geändert).

Es geht nun auf jeden Fall wie gewünscht mit beiden Sensorarten, also vielen Dank für eure Zeit und eure Ideen!

Cu
Frank