Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - StefanOHAN

Pages: [1] 2 3 ... 5
1
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 18, 2019, 20:13:07 »
Hallo Erik

kein Problem, es reicht klar wenn es mit der nächsten Binding-Version gefixt wird.

Den Piezo Speaker würde ich als Signalgeber für Hinweise / Warnungen / Alarme / Störungen, einsetzten wollen.

Es wäre es gut, wenn man zwischen einem Dauerton und einem Pipton unterscheiden kann.

Unten so eine Idee, wie man den PiezoSpeaker über Openhab ansteuern könnte.

>> Channel für das Ein und Ausschalten (Switch)
>> Channel für die Tonfrequenz (Number)
>> Channel für die Intensität der Lautstärke (Number 0-100 ?)
>> Channel für die Anzahl der PipTöne pro Sekunde (Number 0-20 ?) und wenn dieser Wert 0 ist, gibt es einen Dauerton.

Wenn der Switch des Speaker auf ON steht, sollte es dennoch möglich sein, die Werte für Frequenz und Intensität verändern zu können. So könnten man auch ein Anschwellen des Ton oder einen Frequenzwechsel ermöglichen.

viele Grüsse

Stefan

2
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 17, 2019, 08:04:44 »
Hallo Erik

so jetzt laufen seit 2 Tagen die neuen Rules die das Initialisierungs-Verhalten der 3 angeschlossenen IO-16 nach dem starten des System überprüfen.

Das Initialisierungsproblem scheint ein generelles IO-16 V1 (10pol Stecker) (HW-Release 1.2) zu sein.
Es ist egal ob am Stack mit der direkten USB-Verbindung zum Pi oder über den Stack mit der RS485 Extention angeschlossen sind.


Grüsse

Stefan


3
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 15, 2019, 12:59:36 »
Hallo Erik,

ich hätte noch ein Bicklet für den Binding-Wunschzettel.
Das Piezo Speaker Bricklet.

Wenn Dein OK kommt, würde ich es bestellen.

Grüsse

Stefan


4
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 15, 2019, 08:23:21 »
Hallo Erik,

danke für die Rückmeldung.

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.

Name des Brick-Daemon:
Test war erfolgreich, ich konnte beim Konfigurieren des Daemon einen eigenen Namen angeben. Danke für den Hinweis

Zum Thema Initialisierungs Verhalten vom IO-16 das über RS485 angeschlossen ist.
Ein Refresh Befehl über die Konsole hat auch nichts geändert. Siehe Log

Quote
2019-10-15 06:52:45.145 [ome.event.ItemCommandEvent] - Item 'Pin1In' received command REFRESH

2019-10-15 06:52:56.940 [ome.event.ItemCommandEvent] - Item 'Pin2In' received command REFRESH

==> /var/log/openhab2/openhab.log <==

2019-10-15 06:53:28.483 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'Test.rules'

==> /var/log/openhab2/events.log <==

2019-10-15 06:53:36.267 [INFO ] [marthome.model.script.System Startup] - now

==> /var/log/openhab2/events.log <==

2019-10-15 06:53:36.300 [INFO ] [lipse.smarthome.model.script.myRules] - check wip IO-16 V1 >> Kein INIT PIN1=Pin1InNULL Pin2In=NULL

Über eine kleine Rule fragte ich ab, ob die ITEM den Status NULL haben.

Ich habe vergessen zu erwähnen dass, das IO-16 das hier rum zickte eine HW-Version 1.2 hat, als noch zu den V1 Bricklets mit den 10pol Stecker gehört (hat aber die aktuelle FW).
Aus Interesse habe ich dann mein IO-16 V2 (mit dem 7Pol Stecker) zusätzlich an dem Stack2 (der über RS485 angebunden ist) angeschlossen. Anschließen habe ich das System heruntergefahren, an beiden Stack die Spannung abgeschaltet und anschließen neu gebootet. Der V2 IO-16 hat sich sauber Initialisiert. Dort waren 14 Ports als Input und 2 als Output konfiguriert. Alle!! 14 Input-Ports hatten den korrekten Staus (OFF). Ich hatte gestern allerdings nicht mehr Zeit um es mehrfach zu testen.
Heute werde ich mal einen Überwachungs-Rule für alle IO-16 schreiben um das Verhalten über einen längeren Zeitpunkt beobachten zu können.

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.

Jetzt noch ein zwei Frage zum Verständnis:

im Konfigurations Punkt der verschiedenen Bricklets findet man immer den Menu-Punkt
Bridge Selection
CREATE BRIDGE


Was ist die Funktion zur erstellen einer "Bridge" ?

Nochmal einen Frage zur Sample Rate des Humidity V2 Bricklet
Du schreibst
Quote
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


Quote
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 ?

Viele Grüsse

Stefan

5
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 13, 2019, 17:39:16 »
Hallo Erik,

ich hoffe Du hattest einen erholsamen Urlaub :-)

Ich hab mal alle mir verfügbaren Bricklets und MasterExtentions in meine Konfiguration integriert.
Um nicht Altlasten aus den vorhergehenden Test versehentlich zu übernehmen, wurde das System  komplett zurückgesetzt.
Aktuell nutze ich Dein Beta11 Binding.

Zwei Punkte sind mir aufgefallen

Punkt 1)

Nachdem ich über „PaperUI“ / Inbox das LCD 128x64 erneut hinzu gefügt hatte, und die Channel-Verlinkung über der Item-Datei eingetragen habe, ist mir aufgefallen dass der Channel-String nach dem zurücksetzten von Openhab sich verändert hatte. (siehe unten)

Quote
vor dem Rücksetzten
Number LCD128x64_BL   "LCD128x64 Backlight [%s]" (TestTF)  {channel="tinkerforge:lcd128x64:f80007d9:HQJ:LCD128x64Backlight" }

Nach dem Rücksetzten
Number LCD128x64_BL   "LCD128x64 Backlight [%s]" (TestTF)  {channel="tinkerforge:lcd128x64:b0b51208:HQJ:LCD128x64Backlight" }

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 ?)

Punkt 2)
Ich habe in Summe 3 x IO-16 angeschlossen.
2 x IO 16 sind an dem Materbrick (Stack1) angeschlossen der direkt per USB mit dem Raspberry Pi verbunden ist. 1 x 16-IO ist an dem Masterbrick (Stack2) angeschlossen der per RS485 Extention mit dem Masterbrick des Stack1 verbunden ist.
Stack2 verfügt über eine eigene Spannungsversorgung durch ein StepDown Power-Supply.

Beim Starten von Openhab (egal ob beide Stack‘s Spannungslos waren oder ob nur Openhab neu gestartet wurde) verhält sich das 16-IO das am Stack2 über die RS485 Extention angebunden ist, anders als die 2x16-IO die am Stack1 mit direkter USB-Verbindung am Pi angeschlossen sind.

Die als Input konfigurierten Ports am Stack1 (direkt per USB angeschlossen) werden richtig initialisiert, d.h. es wird angezeigt ob der Input-Kontakt offen oder geschlossen ist.

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 ?

Beispiel: „Die Lüftung soll eingeschaltet sein wenn das Fenster geschlossen ist“ nach dem Startup von Openhab kann das Fenster auf oder zu sein, die Rule wird nicht reagieren.
Auf dem Bild siehst die Du Konfiguration (Brickviewer & PaperUI/Control) man kann erkennen dass das IO-16 (mit ID WiP) nur "ausgegraute" Switch-Symbole hat.
Mir ist momentan unklar wie ich diese Problem umgehen kann, dass meine Input-Item auch direkt nach dem Start den korrekten Status anzeigen.


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 ?

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


Viele Grüsse

Stefan


6
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 08, 2019, 21:27:55 »
Hallo MacDuff

ich habe Deine Rule kopiert und angepasst (Item-Namen) und bei mir funktioniert es.

Einziger unterschied ist, dass Dein ITEM-Name ausschließlich aus Grossbuchstaben besteht.
Wenn ich mich dunkel erinnere, gibt es eine Syntax für ITEMs
"Das erste Zeichen muss ein Grossbuchstabe sein, aber es drüfen nicht alle Zeichen Grossbuchstaben sein."

Probier mal, ob bei Anpassung der ITEM-Namen-Syntax das Problem behoben ist

Meine Item/Channel verlinkung  sieht wie folgt aus
Quote
String LCD20x4_text "LCD20x4 [%s]" (TestTF) { channel="tinkerforge:lcd20x4:b0b51208:abc:LCD20x4Text"}

Grüsse Stefan

7
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 08, 2019, 21:16:13 »
Hello Wannes,

I changed my configuration

Now I have Stack2 with
-step-down Power Supply
-RS485 Extention Slave (connected with the RS485 Extention on Stack1)
-Masterbrick 2.1
 ->Dualrelais V2
 ->Industrial In V2

at Stack2
-RS485 Extenion Master
-Masterbrick 2.1 (is via USB conneted with the Raspberry)
 ->IO-16 V2

One Port of the 16-IO (Port 0 = Item Pin0) is at the ITEM-File configured as an Input.

If I switch the DualRelais"0" ON, the Idustrial-IN geht on Port3 5V power.

with that Rule I can switch on/off DualRelais"0"
Quote
rule "test dualrelais "
    when
        Item Pin0 changed to ON
    then
   
    if (DualRelay1.state != ON ) { DualRelay1.sendCommand (ON) } else { DualRelay1.sendCommand (OFF) }
end

During my test I was switch 4 Time on/off the Powersupply at Stack2.

But I get no error, the rule was working and via the rule I could swith on/off the DualRelais"0" and even the Industrial-IN Port3 was switching to on/off if the Rule switched the DualRelais on/off.

maybe there is an other difference between our configurations

Greetings Stefan

8
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: October 08, 2019, 08:54:33 »
Hello Wannes,

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

Does it mean you can't send command with rules to the Stack ?

I want to reconfigure my Test-System and try if I even get the same Problem.



with regards Stefan

9
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 29, 2019, 13:39:23 »
Hallo Erik,

erst mal schönen Urlaub für Dich :-)

Beim LCD 128x64 funktioniert jetzt das Backlight :-)
Text schreiben und Display-clear funktionieren analog zum LCD 20x4.
Den Draw-Channel hab ich aus Ideen-Mangel noch nicht getestet.

Jetzt werde ich erst mal ein paar zusätzlichen TF Bricklets bestellen.

@ rak
kurze Frage, hast Du über die karaf-console erst das alte Binding entfernt ?
Ich entpacke den Zip immer auf einen anderen PC (ich nutze einen RasPi 3b ; OS = Openhabian v1.5 ; Openhab = 2.5.0-SNAPSHOT Build #1673), deinstalliere über die karaf-Console das alte Binding, stoppe Openhab und anschließend kopiere ich das Binding in das Addon-Verzeichnis. Nach dem Restart von Openhab funktioniert es wieder.

viele Grüsse Stefan

10
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 26, 2019, 08:58:00 »
Hallo Erik

Test mit Binding 10

der Motion-Dedector funktioniert wieder.

Zum „Weather Temperature/Humidity Sensor TH-6148“
Erik Du schreibst dass dieser Sensor nicht den Batteriezustand liefern kann. Ich konnte auf Euer Website keine Information finden in welchen Zeitintervallen der Sensor Daten übermittelt. Wenn nun der Sensor immer in gleichen (oder fast gleichen) Intervallen die Daten übermittelt, könnte ich eine Rule schreiben die einfach eine Warnung aus gibt wenn der Sensor eine gewisse Zeit keine Daten übermittelt hat.
Frage: Liefert der Sensor immer in gleichen Zeitintervallen Daten, oder nur wenn sich die Werte ändern ?

Weiter mit dem Test

Test LCD 20x4
das Verlinken der verschieden Channel hat funktioniert.
Die Button-Taster melden im Log „triggered PRESSED / RELEASED“

Einschalten und Ausschalten des Backlight sowie Clear des Display über eine Rule (durch betätigen eines der Button), hat problemlos funktioniert.

Probleme hatte ich anfangs mit der Formatierung des String für die Textausgabe auf dem Display.
Mit etwas Testen habe ich dann erkannt, dass der gesamte Ausdruck in Hochkomma gesetzt werden muss.

Quote
rule "LCD20x4 Text schreiben"
    when
        Channel "tinkerforge:lcd20x4:b0b51208:abc:LCD20x4Button1" triggered
    then
    LCD20x4_text.sendCommand("1,1,Test new" + " addon")
end

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). Es ist etwas unpraktisch wenn das Backlight nicht direkt angesteuert und verändert werden kann.

Noch einen Frage zum MasterBrick:
Nachdem ich in meiner grössten Installation 3 MasterBick-Stapel (die alle über USB angeschlossen sind) nutze, dachte ich mir, es wäre gut wenn man die Master-Brick's per Rule überwachen kann. Nachdem ich in Zukunft auch die RS485 Extention nutzen will wäre diese Funktion sehr hilfreich.
Frage: Sieht Du die Möglichkeit eines Channel (online/offline) für den MasterBrick die per Trigger in einer Rule verarbeitet werden kann ?

Grüsse

Stefan

11
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 25, 2019, 08:36:36 »
Hallo Erik,
Heute habe ich mit dem Beta9 Binding weiter getestet.

Leider funktioniert jetzt der Motion-Dedector nicht mehr. Ich habe Ihn aus der Konfiguration entfernt, dann das System neu gestartet und erneut als Thing hinzugefügt, aber er reagiert nicht mehr. (nach abgeschlossenen Test habe ich das Beta7 Binding wieder eingespielt und der Motion-Dedector funktionierte wieder).

Fehlermeldung im Log:

Quote
2019-09-24 19:39:53.633 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler@88e18a': null
java.lang.NullPointerException: null
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.buildChannel(DeviceHandler.java:206) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.configureChannels(DeviceHandler.java:238) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:117) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.201909190301]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.201909190301]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
==> /var/log/openhab2/events.log <==
2019-09-24 19:39:53.682 [hingStatusInfoChangedEvent] - 'tinkerforge:motiondetectorv2:b0b51208:Hz1' changed from INITIALIZING to UNINITIALIZED (HANDLER_INITIALIZING_ERROR)
==> /var/log/openhab2/openhab.log <==
2019-09-24 19:39:53.685 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'tinkerforge:motiondetectorv2:b0b51208:Hz1': null
java.lang.NullPointerException: null
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.buildChannel(DeviceHandler.java:206) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.configureChannels(DeviceHandler.java:238) ~[?:?]
        at org.eclipse.smarthome.binding.tinkerforge.internal.handler.DeviceHandler.initialize(DeviceHandler.java:117) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152) [133:org.openhab.core:2.5.0.201909190301]
        at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [133:org.openhab.core:2.5.0.201909190301]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

Weiter im Test:

Test 16-Fach-IO output
nach Rekonfiguration und Anpassen des Verlinkten-Channel in der ITEM-Datei, konnte ich über die PaperUI/config den Switch für den Port betätigen und eine kleine LED ein und ausschalten.

Test Outdoor Weather Bricklet / Outdoor Weather Temperature/Humidity Sensor TH-6148 :

Über „Bridge Selection“ konnte ich meinen Sensor Typ TH-6148 hinzu fügen. Anschließend habe ich in der ITEM-Datei die 3 sichtbaren Channel verlinkt. Die Temperatur / Luftfeuchte und die letzte Änderung wurden sauber angezeigt.

Frage zum Outdoor Weather Temperature/Humidity Sensor TH-6148 :
Erik, ist es möglich auch noch einen „Batterie“ Status anzeigen zu lassen ?

Im laufe der Woche werde ich das 128x64 LED Testen.

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.

@ Ulf, @ Max, wie wollen wir das mit den Beispielen machen ? Was hättet Ihr für Vorschläge ?



Viele Grüsse Stefan

12
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 24, 2019, 09:09:01 »
Hallo Erik

Gestern habe ich weitere Funkionen und Bricklets per Channel-Verlinken getestet.
Noch mit Binding Beta7, Beta8 werde ich heute Abend testen (output 16-Fach-IO)


Test Tinkerforge Humidity Bricklet 2.0
Humidity / Temperatur konnte ich problemlos mit Number-Items verlinken, den Heater mit einem Switch-ITEM.
Die „sampel-rate“ habe ich auf 0.1 eingestellt, hat auch wunderbar funktioniert.

Temperatur und Luftfeuchte werden sauber angezeigt, wenn ich das Heater-Switch-Item betätige sieht man dass sich die Werte für Luftfeuchte und Temperatur verändern, somit dürfte der Heater funktionieren.

Frage: Mit „Humidity Moving Average Length“ habe ich doch Einfluss auf das Messverhalten bei Schwankungen, wie muss ich diese Werte interpretieren ? z.B. „10“ bedeutet nur Schwankungen > 0.1    ? (in der Werte Auflösung sehe ich 2 Nachkommastellen, daher meine Vermutung)

Test Tinkerforge Multi Touch Bricklet:
Alle Electroden-Channel konnte ich mit Switch-Item verknüpfen, beim berühren haben die Switch-Item den Status auf ON und wieder auf OFF gewechselt. 

Test Tinkerforge Industrial Quad Relay Bricklet 2.0
Hier habe ich jetzt noch ein String-Item für das Monoflop Relay0 verlinkt und wenn ich über die „PaperUi / Control“ Website den „trigger“ betätigte hat das zugehörige Relais auf ON und anschließend wieder auf OFF gewechselt. Hat gut funktioniert.

Hierzu hätte ich eine Frage:
Ich habe anschließende per Rule die Trigger-Funktion auslösen lassen. Ich hätte vermutet dass ich dem String des verlinkten Monoflop dem Werte „triggerd“ oder „TRIGGER“ zuweisen muss.
Dies hat auch funktioniert, das zum Monoflop zugehörige Relay hat sich ein und anschließend wieder ausgeschaltet.
Frage: „Ist es egal welchem Wert man dem String zuweist ?“ Ich hab mit verschieden Schreibweisen gearbeitet und es hat immer geklappt.


Meine Rule
Quote
rule "monoflop-Industrial RelaisR0"
    when
        Item Pin0 changed to ON
    then
        QuadV1MF.sendCommand(„TRIGGER“)
end


letzter Test des Tage „Spannungs-Ausfall am Remote-Master-Brick-Stapel“

Mein Master-Brick Nr2 ist über eine RS485 Extension mit Master-Brick Nr1 verbunden. Master-Brick Nr 1 ist über USB mit dem Pi verbunden.
Am Master-Brick Nr2 ist ein 16-FACH-IO angeschlossen, für diese habe ich einen INPUT Channel mit einem Switch-ITEM verlinkt. An diesem ist ein Schließer-Taster angeschlossen.
Test Spannungsabfall am Remote-Stapel
Bei Ausfall der Versorgungsspannung behält das ITEM seinen Status, wenn während der Zeitspanne zwischen Spannungsausfall und Wiederherstellen der Spannungsversorgung der Zustand des „Realen-Taster“ verändert wird, hat nach Wiederherstellen der Spannungsversorgung das ITEM einen entsprechenden Update erhalten.
Auch dieser Test war aus meiner Sicht erfolgreich

Viele Grüße

13
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 23, 2019, 10:28:45 »
Hall Ulf, hallo Erik

Ulf danke für den Hinweis, ich konnte zwar die Config jetzt umstellen (danke Deines Hinweises) Aber wie bei Dir, kommt die gleiche Fehlermeldung im Log und das Bricklet hat den Status "UNINITIALIZED-HANDLER_INITALIZING_ERROR" unter ../Configuration/Things.

Allerdings ploppt bei mir eine PopUp-Fenster hoch.

Ulf kurze Frage: Kontest Du mit dem Output arbeiten ? Bei mir hat das ganze 16-Fach IO den Betrieb eingestellt.

Ich habe mich dunkel daran erinnert, dass Theo's 1er-Binding nur funktionierte wenn mann alle A oder B Ports entweder auf Input oder auf Output konfiguriert Ein Mix von Input und Output im in einem Port (A oder B) funktionierte nicht.

Ich stelle dann alle Pins des A-Port auf Output, ohne Erfolg. Auch eine Konfiguration aller Pins auf OUTPUT funktioniert nicht.

Jetzt mal so eine Frage in die Runde, wäre hätte den Lust gemeinsam mit mir hier in einem separation Post Konfigurations-Beispiele zu pflegen ?
Ich glaub es wäre auch für Neueinsteiger etwas einfacher wenn wir hier und nicht unter Openhab soetwas pflegen würden, oder was meint Ihr ?

viele Grüsse

Stefan

14
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 22, 2019, 21:08:57 »
Hallo Erik

heute habe ich in der „ITEM.item“ verschiedene Channel mit Items verlinkt.
Unter Configuration/System ist bei „Item Linking“ der Simple-Mode abgeschaltet.
Als Binding kam Deine Beta 6 zum Einsatz.

Test Industrial Quadrelay v2:
Das Verlinken in der Item-Datei hat funktioniert, das Relais konnte über die PaperUi bedient werden.  :)

Test MotionDetector V2:
die 3 LED‘s habe ich über Number-Items mit den Channels verlinkt. Über zwei Rules  die Trigger-Channel „MotionDetected“ und „DetectionCycleEnded“ zum ein und ausschalten der 3 LED genutzt. Hat ohne Probleme funktioniert.  :)

Test 16-Fach-IO V2
Das Konfigurieren eines „Input-Channel“ des 16-Fach-IO hat wunderbar geklappt

So sieht mein Eintrag in der „ITEM.item“ Datei aus. Der Port reagiert als Öffner (wenn GND mit B0 verbunden wird)
Quote
Switch Pin8    "16fach B0 input [%s]" (TestTF)  {channel = "tinkerforge:io16v2:b0b51208:HHb:IO16V2InputPin8"}

Allerdings bin ich beim Output konfigurieren gescheitert  :'(

Laut Deiner kurz Doku
Zitat
Quote
Pin Configuration 0/A0 (choice): Configures the direction of pin 0/A0. Inputs without pull-up will be floating if nothing is connected. Outputs can have an initial state of low or high.

Hätte ich vermutet dass unter ../Configuration/Things/ eine Auswahl bezüglich input und output getroffen kann. Ist aber nicht so.
Ich habe es dann auf Gut-Glück mit folgender Verlinkung versucht (einfach Input durch Output ersetzt), dies funktionierte nicht (es kam auch eine entsprechende Fehler Meldung im LOG)
Update: Frage der Konfiguration hat sich erledigt

Quote
Switch Pin9    "16fach B1 out [%s]" (TestTF)  {channel = "tinkerforge:io16v2:b0b51208:HHb:IO16V2OutputPin9"}

Mit den anderen Optionen für das 16-Fach IO kann ich nichts anfangen, da diese mir nichts sagen.

Zwei Fragen hätte ich:
1) für was nutze ich den „Edge Count Pin 1/A1“ nachdem er Item-Typ Number hat, kann er doch nur zum Zählen genutzt werden, oder ?
2) wie müsste mein Verlinken in der ITEM-Datei aussehen wenn ich einen Output konfigurieren möchte. Und muss ich unter ../Configurations/Things noch etwas anpassen ? Update vom 23.09.2019 dank Ulf's (Business Tux) hat sich diese Frage erledigt

Weiter Bricklets werde ich im laufe der Woche über die Item-Datei mit den Channel‘s verlinken und testen.

Viele Grüße
Stefan

P.S. meine Hw-Konfiguration: Raspi3 mit „HAT Brick“ daran angeschlossen Multi-Touch / LCD-128x64  / LCD 20x4 sowie ein  Master-Brick Nr1 (v2.1) über USB an dem RaspPi angeschlossen. Im Stapel des Master-Brick Nr1 befindet sich eine RS485 Extension, die die Verbindung zum Master-Brick Nr2 (v2.1) herstellt. Der Master-Brick Nr2 wird durch ein separates Netzteil mit Spannung versorgt. Am Master-Brick Nr2 ist der Motion-Dedector V2 sowie ein 16-Fach-IO (V2) angeschlossen.
Bisher hatte ich immer Probleme mit dieser Konfiguration, da nach einem Restart nicht immer alle Bricklets am Stapel des Master-Brick Nr2 online gingen. Ich habe heute mehrfach das Openhab System als auch den Pi neu gestartet, und es gingen immer all Bricklets online  :D

15
Allgemeine Diskussionen / Re: Betaversion der openHAB-Bindings
« on: September 17, 2019, 09:28:09 »
Hallo Erik,

danke erstmal für die neue Beta.

Zu meiner Frage zum LCD128x64, das LCD hat ja eine Touchscreen und hier hatte Theo die Funktionen über actions verfügbar gemacht.
Quote
Channels
Display (textcommand)
Button 0-11 (system.rawbutton => TriggerChannel)
Slider 0-5 (DecimalValue 0-42)
Tab 0-9 (TriggerChannel)
z.B.
actions.setGUIButton(0, 0, 0, 60, 20, "MeinButton0")

Das habe ich jetzt so nicht in der Doku Deines ZipFile gefunden

Oder sind die Action analog zu Theos Beschreibung schon verfügbar da diese über ander API bereit gestellt werden ? (komme leider erst am Sonntag dazu, das zu tesen). Und wenn ja wo finde ich diese Information


Viele Grüsse

Stefan

P.S. Ich hoffe Dich nerven meine Fragen nicht. Ich vermute dass viele Informationen bereits irgendwo bei Tinkerforge zu finden sind. Bisher hatte hier Theo auf Git Kurzbeispiele für Openhab abgelegt, die das ganze etwas einfacher zu verstehen machten.
Ich vermute Du testest die Funktionen der Bricklets in Openhab, wie sehen Deine Test so aus ? Item-Datei mit Item & Channel usw ? Rule-Datei mit Actions ?

Pages: [1] 2 3 ... 5