Jump to content

rtrbt

Administrators
 Profil anzeigen  Aktivitäten des Benutzers anzeigen

  • Gesamte Inhalte

    1.548

  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    150

 Inhaltstyp 

Posts erstellt von rtrbt

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Gut, dass sich das WLAN-Problem behoben hat. Ist auch für mich hilfreich zu wissen, was die Ursache war, der nächste User mit dem Problem kommt bestimmt.

    Bezüglich der clearDisplay-Action bin ich immer noch nicht schlauer. Ich habe mal eine neue Installation mit Milestone 5 getestet, kurz geflucht, weil die Bindings nicht mehr kompilieren wollten und den Fehler gefixt (das landet in der nächsten Beta, damit die Bindings mit Milestone 5 funktionieren). Nachdem ich dann die ganzen IDs angepasst habe, funktioniert deine Rule, auch mit clearDisplay(). Danach habe ich openHAB neu gestartet und habe jetzt den selben Fehler wie du. Das ist anscheinend nicht deterministisch kaputt.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    vor 16 Stunden schrieb StefanOHAN:
    Frage : habe ich bei der Schreibweise einen Fehler übersehen ?
    Zitat

    „lcdActions.clearDisplay()“

     

    getestete Actions LCD128x64:

    lcdActions.clearDisplay() KO erzeugt einen Fehler im Log

    Zitat

    „2019-11-17 13:54:23.982 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'LCD128x64-action3-Tab': Instance is not an BrickletLCD20x4Actions class.“

     

    Das ist echt verwirrend. Die Fehlermeldung sollte nur ausgegeben werden, wenn die Actions-Klasse mit einer falschen Instanz aufgerufen wird. Das kannst du (meines Wissens) in den Regeln aber nicht erzeugen, ich hatte diese Meldung bei mir nur wegen dem Caching-Problem immer mal gesehen. Das seltsamste daran ist, dass eine LCD20x4Actions-Instanz erwartet wurde, anstelle von einer LCD128x64Actions.

    Ich habe das bei mir getestet und es funktioniert problemlos. Welche openHAB-Version hast du genau laufen? Dann würde ich das nochmal mit genau deinem Setup zu testen.

    Du kannst natürlich übergangsweise den clearDisplay-Channel benutzen. (Der nimmt einen StringType, der Wert ist egal, du kannst ihn also mit [item].sendCommand("Blah")) Da musst du aber aufpassen, wenn du Channel- mit Action-Verwendung mischt: Das sendCommand ist asynchron, wenn du direkt danach auf das LCD zeichnest, ist das schneller als das clear-Command, dann wird das danach gezeichnete auch gelöscht.

    vor 16 Stunden schrieb StefanOHAN:
    Frage: zu drawText
    Zitat

    lcdActions.drawText(0,55,6,true,“Hallo“)

    wie wird diese Action benutzt ?

    Ich hatte keine Reaktion am Display, erwartet hätte ich einen Text Schriftgröße 2x32 , Schriftfarbe schwarz. Muss ich ähnlich wie beim e-Paper noch eine weitere Actions ausführen ?

    Nein, das sollte so funktionieren. Ich habe das auch gerade mal hier ausprobiert, da ist mir aufgefallen, dass du da statt normalen Anführungszeichen (denen hier), spezielle Unicode-Zeichen für die linken Anführungszeichen hast (diese hier). Macht dein Texteditor da Mist?

     

    vor 16 Stunden schrieb StefanOHAN:

    Frage:

    Was kann ich mit dem Channel „LCD128x64SelectedGUITab“ anfangen ?

    Ich hätte vermutet, dass das mit dem Channel verlinkte Number-Item, die „ID“ des berührten TAB erhält (ich erhalte immer „1“ als Rückgabe Wert)

    Hm, das funktioniert bei mir. Teste mal dieses Minimalbeispiel: 

    rule "startrule"
when
    System started
then
    var lcdActions = getActions("tinkerforge", "tinkerforge:lcd128x64:8e8df7e6:HQ6")
    lcdActions.clearDisplay()
    lcdActions.removeAllGUI()
    lcdActions.setGUITabConfiguration(3, false)
    lcdActions.setGUITabText(0, "Tab A")
    lcdActions.setGUITabText(1, "Tab B")
    lcdActions.setGUITabText(2, "Tab C")
end

    und sieh mal nach ob du mit log:tail dann Zeilen wie diese hier siehst, wenn du das Item angelegt hast:

    09:58:58.783 [INFO ] [smarthome.event.ItemStateChangedEvent] - HQ6_SelectedTab changed from 1 to 2

    vor 16 Stunden schrieb StefanOHAN:

    Frage:

    Slider Number-Wert

    Das mit dem LCD128x64GUISlider1 verlinkte Number-Item hat bei mir einen Wert von 0-52. Kann man den Maximal Wert konfigurieren ? Wenn der Slider am Ende seiner Skala ist z.B. einen Wert 10 hat oder auch 100 hat ?

    Nein, der Wert ist immer in Pixeln. Das musst du dir dann hinterher zurecht skalieren, z.B mit (ungetestet!) Math.round(([item].state as DecimalType) / 52.0 * 10)

    vor 17 Stunden schrieb StefanOHAN:

    Eine Frage hätte ich noch zur WIFI-V2 Extension:

    Sie läuft soweit gut, ich sehe nur so ziemlich genau alle 6 Stunden einen kurzen Verbindungsabbruch im OpenHab Log. Nach ca. einer Minute steht die Verbindung auch wieder und zugehörige Dämon ist wieder online.

    Kann es sein, dass diese Master-Extension Zyklisch (müsste ich da evtl. was rekonfigurieren ?) einen Verbindungsabbau / Aufbau ausführt ? Oder meinst Du es liegt an der Konfiguration meines WLAN-Router ? (AVM 7590).

    Das ist nicht schlimm, es ist nur aufgefallen als ich heute morgen mal die Logs kontrollierte.

    Dazu hätte ich folgende Fragen:

    1. Wie sieht dein Aufbau genau aus? Also wo läuft openHAB? (auf einem Raspberry oder so?), was hast du an der WIFI-Extension? usw.
    2. Was steht genau im openHAB-Log? Häng am besten mal die ganze Datei an
    3. Steht etwas brauchbares im Log der Fritzbox?

    Das der Rest funktioniert freut mich schonmal. Nochmal danke dafür, dass du so rigoros testest :)

    Gruß,

    Erik

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Bei der E-Paper-Regel fehlt noch ein draw()-Aufruf, so funktioniert es: 

    val ePaper = getActions("tinkerforge", "tinkerforge:epaper296x128:8e8df7e6:Jn6")
ePaper.fillDisplay(0)
ePaper.drawText(0,0,9,1,0,"test")
ePaper.draw()

    Das ist im Moment ungünstig dokumentiert, aber auch draw(Text/Box/Line) und fillDisplay schreiben nur in den Buffer, damit tatsächlich auf das Display gezeichnet wird muss immer draw() aufgerufen werden. Die Doku passe ich nachher mal an.

     

    Die LCD/IO16-Regel war etwas verwirrender, nachdem ich da mal rumgesucht habe, bin ich über diesen Post gestolpert. Da sieht man, dass [item].state dir eine Instanz von State gibt. Wenn die nicht in einen Zahltyp gecastet wird, klappen keine Vergleiche mit Zahlen. So funktioniert es bei mir: 

    LCD128x64_text.sendCommand("1,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-")

val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:8e8df7e6:H5r")

H5r_EdgeCountPin0A0.sendCommand(REFRESH)

if ((H5r_EdgeCountPin0A0.state as Number).intValue > 10) {
    if(null == ioActions) {
        logInfo("actions", "Actions not found, for io4v2")
    } else {
        logInfo("actions", "Actions found, for io4v2")
        ioActions.getEdgeCount(0, true)
    }
}

LCD128x64_text.sendCommand("2,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-")

    So wie die Regel da steht, hat sie aber noch ein anderes Problem: Der REFRESH ist asynchron, das heißt, du siehst bei den beiden Ausgaben immer den selben Wert, weil der aktualisierte noch nicht da ist, wenn das zweite LCD128x64_text.sendCommand passiert. Alternativ kannst du folgendes machen, dann verhält es sich eher so, wie man es erwartet: 

    LCD128x64_text.sendCommand("1,0,fl-P0-in-G7y-" + H5r_EdgeCountPin0A0.state + "-")

val ioActions = getActions("tinkerforge", "tinkerforge:io16v2:8e8df7e6:H5r")
if(ioActions === null) {
    logInfo("actions", "Actions not found, for io4v2")
    return
}

val currentEdgeCount = ioActions.getEdgeCount(0, false).get("count") as int

if (currentEdgeCount > 10) {
    val currentEdgeCount = ioActions.getEdgeCount(0, true).get("count") as int
}

LCD128x64_text.sendCommand("2,0,fl-P0-in-G7y-" + currentEdgeCount + "-")
H5r_EdgeCountPin0A0.sendCommand(REFRESH)

    Da sieht man auch gut, warum ich noch auf meiner TODO-Liste stehen habe, für Actions die nur einen Wert zurückgeben, den direkt rauszuführen und nicht über den Map<String, Object>-Ansatz zu gehen. Dann fällt das ganze ".get("count") as int" weg.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    vor 11 Stunden schrieb StefanOHAN:

    Wie ist Deine Vorgehensweise beim aktualisieren des Binding ?

    Hm das war ungünstig formuliert. Mit aktualisieren meinte ich, die JAR im Addons-Verzeichnis mit der neuen zu überschreiben. Also was ich mache ist (während openHAB läuft):

    • Die JAR durch die neue ersetzen
    • Warten bis im Log (log:tail) die Reinitialisierung durch ist. Das dauert typischerweise so 20 Sekunden. (Ich habe eine Regel, die eine LED auf Grün setzt wenn System started triggert, das ist alternativ auch ein guter Indikator)
    • openHAB neustarten, wieder auf die grüne LED warten

    Das hilft typischerweise, ist aber etwas Cargo-Kultesk. Da die anderen Actions bei dir aber funktionieren, vermute ich, dass du nicht das Cachingproblem hast.

    vor 11 Stunden schrieb StefanOHAN:

    Meine Interpretation war, dass ich eben mit der „action“ getEdgeCount(Channel0 , false) eben nicht den Counter reset ausführe.

    Das ist auch so. Was ich meinte ist, dass du in deiner ursprünglichen Regel die Action mit false aufgerufen hast, was dir den aktuellen Wert gibt, mit dem hast du dann aber nichts gemacht, deshalb hast du keine Änderung gesehen. Es gibt da 4 sinnvolle Varianten was du in einer Rule machen kannst:

    • ioActions.getEdgeCount(0, true): Das setzt den Zähler zurück, den aktuellen Wert verlierst du dabei.
    • val x = ioActions.getEdgeCount(0, true): Das setzt den Zähler zurück, den alten Wert hast du dann in x und kannst irgendwas damit anfangen.
    • val x =  ioActions.getEdgeCount(0, true): Das setzt den Zähler nicht zurück, den alten Wert hast du dann in x und kannst irgendwas damit anfangen.
    • Pin0IO4V2Count.sendCommand(REFRESH): Das aktualisiert den Zähler in openHAB, du hast aber nicht den Wert sofort zur Hand. Damit kannst du aber natürlich eine separate Regel triggern, die auf den Channel-Wert reagiert.

    Mit  ioActions.getEdgeCount(0, true) fragst du nur den Wert ab und verlierst ihn dann, der Zähler wird aber nicht zurückgesetzt, deshalb passiert dann nichts.

    Perspektivisch kannst du dir das ganze Refreshen aber sparen, dass muss ich sowieso für Werte, die sich nicht automatisch aktualisieren, allgemein lösen, damit wird der Edge Counter dann auch erschlagen.

    Die Bearbeiten-Funktion des Forums war tatsächlich seltsam, die Standardkonfiguration ist wohl, dass man nur 5 Minuten lang den letzten Post bearbeiten darf. Das habe ich mal geändert.

    Die LCD/E-Paper-Regeln teste ich mal und melde mich nochmal, eigentlich sehen die funktional aus.

    Edit: Bei den val x = ioActions.getEdgeCount()-Geschichten muss noch .get("count") as int hinten dran, siehe den nächsten Post

    HAT Binding Openhab 2

    in Software, Programmierung und externe Tools

    Geschrieben

    Moin,

    Benutzt du die Beta-Version der offiziellen Bindings aus diesem Thread? Dann musst du in der PaperUI von Hand in entweder der Inbox oder Configuration->Things einen Brick Daemon hinzufügen. Die Adresse ist localhost, wenn du openHAB auf dem Raspberry Pi laufen lässt, ansonsten dessen IP-Adresse oder Hostname.

    Wenn du die von Theo geschriebenen Bindings benutzt, sollte das ähnlich funktionieren. Da müsstest du notfalls mal hier nachlesen oder nachfragen.

    Gruß,
    Erik

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Am 8.11.2019 um 18:52 schrieb sihui:

    1) Wie sieht es mit dem Support im Binding für ältere TF Hardware aus? Ich habe z.B. noch ein Remote Switch Bricklet V1 mit dem ich meine ganzen Baumarkt Steckdosen schalte (Weihnachten steht vor der Tür).

    Ich bin über TF überhaupt erst zur Hausautomation gekommen, das ist jetzt fast fünf Jahre her und es wäre schade wenn die älteren Bricklets jetzt aus dem Binding rausfallen.

    Die älteren Bricklets werden unterstützt, nur die Remote Switches fehlen noch (sind aber schon implementiert, kommen mit der nächsten Beta).

    Am 8.11.2019 um 18:52 schrieb sihui:

    2) Ist geplant das Binding in das offizielle openHAB Repository einzubringen? Auch wenn das manuelle Installieren ohne Probleme klappt, es wäre jedoch schöner wenn man das Binding über den üblichen Weg installieren könnte.

    Das kann ich noch nicht versprechen. Auf der TODO-Liste steht noch, rauszufinden wie ich den Code dafür umbauen müsste

    vor 18 Stunden schrieb StefanOHAN:

    Frage: Hast Du die Möglichkeit auch Things der WIFI-Extention einzubinden ? Man kann ja neben dem Client auch den AccesPoint Mode nutzen, da wäre es schön wenn man den AccesPoint Mode ein und ausschalten könnte.

    Eher nicht. Den AccessPoint-Modus kann man nur ausschalten, indem die ganze Wifi-Konfiguration geschrieben wird, das kostet aber wieder EEPROM-Schreibzyklen, deshalb habe ich das in openHAB nicht eingebaut. Extra API dafür einbauen ist auch nicht sinnvoll, weil man sich dann einen Haufen Probleme für andere Anwendungsfälle einhandelt.

     

    Zitat

    The method clearDisplay(ThingActions) from the type BrickletLCD20x4Actions refers to the missing type Object

    2019-11-10 20:29:57.138 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'startrule': Instance is not an BrickletLCD20x4Actions class.

    Die erste Fehlermeldung bekomme ich auch, das scheint aber nichts relevantes zu sein, die Rules funktionieren trotzdem. Die zweite ist wichtiger, openHAB scheint, wenn man die Bindings-JAR aktualisiert, Teile davon in irgendeinen Cache zu laden, der für die RuleEngine nicht korrekt bereinigt wird, nicht mal wenn openHAB neugestartet wird. Was bei mir zuverlässig hilft ist, die Bindings zu aktualisieren, während openHAB läuft und mit log:tail die Ausgabe zu verfolgen. Nach ~ 20 Sekunden tut sich im Log einiges, weil er die Bindings neugeladen hat, wenn du danach openHAB neustartest, läd er nur die neuen Bindings, danach sollte es funktionieren.

    vor 18 Stunden schrieb StefanOHAN:

    Die ClearDisplay Rule sieht wie folgt aus

    Die sieht soweit korrekt aus. Ich gehe mal davon aus, dass das auf das selbe Problem wie oben zurückzuführen ist.

    vor 18 Stunden schrieb StefanOHAN:

    hast Du das Problem mit dem Zählen des EdgeCount schon anpassen können ? oder habe ich die action falsch verwendet ?

    So wie du die Action verwendest, fragst du den Edge Counter ab, aber das Ergebnis wird dann verworfen. Wenn du den Wert von openHAB aktualisieren willst, kannst du in der Rule 

    [itemname].sendCommand(REFRESH)

    aufrufen, wobei [itemname] das EdgeCount-Item ist. Intern ruft das dann auch 

    getEdgeCount(0, false)

    auf, schreibt das Ergebnis aber in das Item.

    vor 18 Stunden schrieb StefanOHAN:

    eigentlich solle es keinen Unterschied machen ob nun variable oder value genutzt wird, oder ?

    Stimmt das ist hier egal. Da war ich nur verwirrt, weil ich davor irgendeine andere Sprache benutzt habe.

     

    vor 18 Stunden schrieb StefanOHAN:

    Leider bin ich diese Woche bis Mittwoch nur sporadisch online, daher kann ich vor nächsten WE nicht weiter testen.

    Kein Problem, ist ja freiwillig :D

    vor 18 Stunden schrieb StefanOHAN:

    Großes Lob an Euren Warenversand, ich habe am Freitag Morgen bestellt und am Samstag war schon alles da.

    Habe ich mal weitergegeben.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

    Frage: Sollte das Number-Item sich nicht um 1 erhöhen wenn ich den als Input konfigurierten Pin betätige ? Bei mit behält das Number-Item den Wert „0“

    Das funktioniert leider noch nicht automatisch, da der Edge Count kein Callback hat, ich also den Getter benutzen muss. Der wird aber nur ausgeführt, wenn du dem Item ein Refresh-Command schickst. Solche Werte automatisch zu aktualisieren steht noch auf der TODO-Liste.

    Meine Rule (sind für die IO16-V1 / V2 und das IO4-V2 immer gleich aufgebaut)

    rule "mono-flop"

        when

            Item Pin0IO4V2 changed to OFF

        then

        Pin2IO4V2mf.sendCommad ("TRIGGER")

      end

     

    rule "mono-flop2"

        when

            Item Pin0IO4V2 changed to ON

        then

        Pin2IO4V2mf.sendCommad ("ON")

    end

     

    Nur das I0-4 V2 erzeugt eine Fehlermeldung (die IO-16 V1 / V2 nicht)

     

    2019-10-27 19:21:40.363 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'mono-flop': 'sendCommad' is not a member of 'org.eclipse.smarthome.core.library.items.StringItem'; line 355, column 6, length 34

     

    Was mache ich falsch ?

    Das sollte sendCommand sein, beim Rotary Encoder 2.0 auch.

    Mir ist heute mit dem neue Binding aufgefallen, dass im Log sich sehr oft diese Meldung für die verschiedenen Bricklets wiederholt.

    2019-10-27 20:04:29.669 [iNFO ] [forge.internal.handler.DeviceHandler] - Checking reachability of H44

    2019-10-27 20:04:29.676 [iNFO ] [forge.internal.handler.DeviceHandler] - Done checking reachability of H44

     

    Ist dies Absicht ?

    Technisch gesehen ja. Das ist der Mechanismus, der prüft ob die Verbindung noch besteht. Die Meldungen hatte ich aber nur testweise auf INFO gesetzt, das sollte eigentlich DEBUG sein, damit es beim normalen Log-Level nicht die Ausgabe überflutet. Repariere ich für die nächste Beta.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Moin,

     

    Beta 12 ist jetzt im Post oben.

     

    @Wannes: The 12th beta version should fix your wifi problems. The bindings now check periodically if a network connection was lost and then try to reconnect.

     

    @StefanOHAN: In der neuen Version ist der Fix für dein IO16-Problem enthalten. Piezo Speaker kommt mit der nächsten Beta, das sollte aber schneller gehen als die letzte ;) Den Speaker als Systemlautsprecher zu benutzen wird nicht gehen, da bräuchte man einen eigenen Treiber oder müsste eine openHAB-AudioSink schreiben.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    @Wannes:

    The problem with the WiFi Extension seems to be, that openHAB does not notice the lost connection caused by the restart of the stack. openHAB then still assumes, that the connection is established, but the Wifi Extension has no open connection because of the restart. Currently the Tinkerforge Protocol has no heartbeat mechanism, so to fix this, I have to query the device state periodically in the openHAB bindings (this will fail if the connection was lost) and then try to restablish lost connections. I think this fix will be in the next beta version.

     

    @StefanOHAN

    Das IO-16-Problem lag an einer fehlerhaften Konfiguration, die Getter, die openHAB für REFRESH-Commands verwenden sollte, hatte ich als Callback eingetragen, was dann später von den richtigen Callbacks überschrieben wurde. Deshalb funktionierte nur das initiale Abfragen des Zustands nicht, die Aktualisierungen aber schon. Brauchst du den Fix dringend oder reicht es, wenn ich den in die nächste Version packe?

     

    Bezüglich dem Piezo Speaker: Support dafür kommt auf jeden Fall noch, ich bin mir nur noch unschlüssig, wie ich den modelliere. Was wäre dein Anwendungsfall dafür/Welche Features hättest du gerne?

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Zum Thema HAT : Ja es ist die aktuelle FW installiert, es hat auch immer funktioniert. Nachdem es nur eine Warnmeldung war, war ich mir nicht sicher ob es was zu bedeuten hat.

    Nur, dass die Initialisierung mehr als 5 Sekunden gedauert hat. Ansich sollte das deutlich schneller gehen, was openHAB auch erwartet, deshalb die Warnung. Kannst du also ignorieren.

     

    FRAGE: Kann es sein dass die Kombination "Verbindung über RS485 Masterextention und alte V1 IO-16 diese Eigenart verursachen ?" Evtl kann ja im Binding nochmal auf den Teil für das alte IO-16 schauen.

    Möglich. Das sehe ich mir nochmal an.

     

     

    im Konfigurations Punkt der verschiedenen Bricklets findet man immer den Menu-Punkt

    Bridge Selection

    CREATE BRIDGE

     

    Was ist die Funktion zur erstellen einer "Bridge" ?

    Das kannst du ignorieren, die Bridge der Things ist der Brick Daemon. Aus irgendeinem Grund zeigt die PaperUI das dort aber nicht korrekt an, steht schon auf meiner TODO-Liste rauszufinden, was da kaputt ist.

     

    Nochmal einen Frage zur Sample Rate des Humidity V2 Bricklet

    Du schreibst

    Du kannst ja beim Humidity Bricklet die Sample-Rate konfigurieren, wenn die wie bei dir auf 0.1 steht, dann misst das Bricklet alle 10 Sekunden. Damit weniger Rauschen auf den Daten ist, gibt das Bricklet aber nicht den Rohwert aus, sondern mittelt die letzten n Werte. Dieses n ist der Humidity Moving Average Length. Standardmäßig sind das 5, d.h. das Bricklet gibt den Durchschnitt über die letzten 5 Messwerte, also 50 Sekunden aus.

     

    ich hatte meine Konfiguation wie unten eingestellt, bekam aber dennoch alle 10 sec einen Wert im Log

    Averaging

    Humidity Moving Average Length 20

    Temperature Moving Average Length 20

    Sample Rate 0.1 SPS

     

    2019-10-15 06:57:43.298 [vent.ItemStateChangedEvent] - Hum1 changed from 48.36 to 48.37

     

    2019-10-15 06:57:53.255 [vent.ItemStateChangedEvent] - Hum1 changed from 48.37 to 48.39

     

    hätte da nicht alle 200 Sekunden nur werte erscheinen dürfen ?

    Das ist etwas subtil, es gibt (ältere) Bricklets, bei denen wäre das so, da sie nicht einen gleitenden Mittelwert (= Moving Average) sondern einfach nur einen Mittelwert (= Average) ausgeben. Das Humidity berechnet aber einen gleitenden Mittelwert. Das heißt, dass das Bricklet die letzten "Moving Average Length" Werte speichert, bei dir also 20 pro Messwert und dann pro neuem Messwert, bei dir alle 10 Sekunden, den jeweils letzten Wert vergisst, den neuen dazu nimmt, den Durchschnitt berechnet und dann ausgibt. Dadurch hast du alle 10 Sekunden einen neuen Wert, der aber über die letzten 20 echten Messwerte geglättet wurde.

     

    Bezüglich der ganzen Dinge, die so aufgelaufen sind: Ich muss mich in der Firma gerade noch um ein paar andere Dinge kümmern, d.h. die nächste Beta wird vermutlich noch ein paar Tage dauern.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Barometer 2.0

    Der Druck von 1.0 bar kommt als ein Wert von 10.0 an, liegt das an mit oder stimmt da was nicht ?

    Das sehe ich mir mal an, sollte so nicht sein.

    UV 2.0

    Bei dem Index steht jetzt bei mir in der Sitemap "one" wo die Einheiten stehen. Das Ding ist natürlich ohne Einheit, is klar, aber ist das ein OH Fehler oder kommt das vom Binding so mit ?

    one ist eine der "Einheitenlos"-Einheiten, wie auch z.B. Prozent oder PPM, das ist so korrekt. Ich kann aber mal nachsehen, ob man das nicht sinnvollerweise ganz ohne Einheit rausgibt.

     

    After power loss on my tinker stack and a power up again the commands from openhab don't seem to come true anymore.

    Only after restart of the binding my relais and inputs work again in openhab.

    The bricks seem to reconnect fine.

    I added a debug log disconnecting and reconnecting again.

    I was on vacation the last two weeks, but will take a look at this soon.

     

    Hallo Erik,

     

    ich hoffe Du hattest einen erholsamen Urlaub :-)

    Hatte ich, danke :D

     

    Es unterscheiden sich die Zeichen in der 3ten Gruppe (alt „f80007d9b“ neu „b0b51208“)

     

    Warum ist dies so ? Kann dies verhindert werden ?

    Was würde passieren wenn ich das System neu aufsetzte ? Müsste ich immer alle Channels neu verlinken ? (wäre es möglich einfach die Item - Datei mit dem verlinkten Channel in das neue System zu kopieren ohne diese ändern zu müssen ?)

    Das ist der (automatisch generierte) Name des Brick Daemons. D.h. wenn du dem Daemon beim Anlegen einen festen Namen gibst, sollten den alle Items als dritte Gruppe haben.

     

    Punkt 2)

    Die als Input konfigurierten Ports am Stack2 bleiben nach dem Starten von Openhab in einem undefinierten Zustand (NULL) solange bis der Input Kontakt 1x betätigt wurde.

    Es ist auch egal ob nun während des Starten von Openhab ein Input-Kontakt geschlossen ist oder nicht.

     

    Dies ist etwas unschön, denn wenn man über den „remote“ Stack2, Fenster oder Türkontakte (IO-16) einbinden will, hat man nach dem Starten von OpenHab keine klare Aussage ob eine Rule nun starten soll oder nicht. Diese Problem könnte man umgehen wenn man den Status eines Channel abfragen könnte, geht dies mit Deinem Binding ? Wenn nein, was kann man da machen ?

    Das sollte natürlich prinzipiell nicht notwendig sein, aber du kannst mit smarthome:send [itemname] REFRESH ein Refresh-Command schicken, dann sollte der Zustand aktualisiert werden.

     

    Ein Punkt ist mir noch aufgefallen, einmal erschien im Log die Meldung dass das Hat länger zum Initialisieren benötigte. Ist dies ein Problem ?

     

    2019-10-13 07:38:57.070 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'tinkerforge:hat:b0b51208:JYv' takes more than 5000ms.

    Das ist etwas seltsam, weil der HAT-Handler eigentlich nicht viel tut, aber wenn das Initialisieren klappt, sollte das kein Problem sein. Hast du die aktuelle Firmware (2.0.1) auf dem HAT?

     

    PS: Danke für die Urlaubsvertretung ;)

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Frage: Liefert der Sensor immer in gleichen Zeitintervallen Daten, oder nur wenn sich die Werte ändern ?

    Der Sensor liefert alle 45 Sekunden Daten. Ich habe das mal an die Channel-Dokumentation angehangen. Da das Outdoor-Weather-Bricklet handgeschrieben ist, erscheint das aber noch nicht in meinem improvisierten Dokumentationsgenerator.

    Mit etwas Testen habe ich dann erkannt, dass der gesamte Ausdruck in Hochkomma gesetzt werden muss.

    Stimmt, der Channel will StringTypes, in Regeldateien brauchst du deshalb die Anführungszeichen.

    Zum LCD 128x64: (hier habe ich noch nicht alles getestet)

    Gibt es für das Backlight nur eine feste "Konfigurationsmöglichkeit, also nicht über Channel‘s. Ist das korrekt ?

    Wenn ja, könnte Du bitte für das Backlight einen Channel einbauen (ähnlich wie beim LCD20x4).

    Hm, das sehe ich mir mal an, eigentlich sollte das ein Channel sein.

    Frage: Sieht Du die Möglichkeit eines Channel (online/offline) für den MasterBrick die per Trigger in einer Rule verarbeitet werden kann ?

    Das könnte eventuell gehen. Rausfinden, ob ein Master Brick offline ist, ist nicht ganz trivial, aber da kann ich eventuell was bauen.

    Betaversion der openHAB-Bindings

    in Allgemeine Diskussionen

    Geschrieben

    Leider funktioniert jetzt der Motion-Dedector nicht mehr.

    Da ich habe beim Umbauen der Channelrekonfiguration eine Feinheit für Trigger-Channel übersehen, das wird mit Beta 10 (heute Nachmittag) wieder funktionieren.

    Frage zum Outdoor Weather Temperature/Humidity Sensor TH-6148 :

    Erik, ist es möglich auch noch einen „Batterie“ Status anzeigen zu lassen ?

    Nein, da das der Sensor selbst nicht meldet.

    Erik noch eine Frage zum NFC-Bricklet, was planst Du alles für diese Bricklet ?

    - Ich würde es gerne für Security Themen verwenden, wenn ich das richtig verstanden habe muss dazu aber auf einen gesicherten Bereich zugegriffen werden.

    Geplant ist, für das NFC-Bricklet die API für einfache Anwendungsfälle zu erweitern und dann mit openHAB diese API zu verwenden, da die aktuelle API zu komplex ist um sie abbilden zu können. Das wird aber noch eine Weile dauern.

×
×
  • Neu erstellen...