Garagentor via NFC öffnen

    Habe gestern mal wieder ein paar Minuten dafür Zeit geopfert.

    Vom Blockly habe ich mich getrennt, da man hier als Ereignis kein "any" einfügen kann.

    Jetzt passiert folgendes:

    Halte ich den Chip mit der Nummer 305247091 an den Sensor, kann ich unter Objekte im domotcz.in ganz kurz eine Reaktion in Form eines Wertes sehen. Aber nur ganz kurz.

    Dann erscheint im Log die Nummer des Chips. Also bis zur Zeile 12 "log(obj.svalue);" sieht alles gut aus.

    Das nachfolgende if jedoch führt keine Aktion aus.

    Ich habe in Zeile 18 beim Rücksetzen des domoticz.in-Wertes ein Delay eingesetzt. Hoffe, dass es so zumindest Syntaxtechnisch richtig ist. Vielleicht kann man dann etwas besser sehen, ob der richtige Wert dort erscheint und das Script erst nach der vorgesehenen Zeit den Wert killt.

    hier mal der Auszug aus dem Log:

    Könnte es sein, dass man nicht einfach Null in den Wert von domoticz.in schreiben kann? Muss das eventuell im JSON Format sein?

    Zitat von Ati

    Wrong type of mqtt.0.domoticz.in: "number". Please fix, while deprecated and will not work in next versions.

    lässt zumindest darauf schließen, dass eine einfache Nummer nicht erlaubt ist.

    Ich würde es mal mit "leer" versuchen: setStateDelayed('mqtt.0.domoticz.in', '', 1000);

    Zwar nicht gerade die feine, englische Art, aber zum testen... ;)

    Warum willst/musst du den state eigentlich löschen?

    Zitat von Ati

    Das nachfolgende if jedoch führt keine Aktion aus.

    Doch, sonst kämen auch die ganzen Fehler nicht. Siehst du auch anhand von #19 log("hm-rpc.2.000218A9916FDA.3");

    ...und dann im Auszug Log: #31 javascript.0 2018-07-09 13:00:26.665 info script.js.common.Garagentor_NFC_Java: hm-rpc.2.000218A9916FDA.3

    Das kommt nur wenn die IF-Bedingung "true" ist, denn nur dann werden die Befehle in den {} ausgeführt.

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    Zitat von SBorg

    Warum willst/musst du den state eigentlich löschen?

    Eigentlich nur, damit eine Veränderung erkannt wird. Bleibt ein Wert drin, reagiert sonst das Script nicht mehr, da es keine Aktualisierung registriert. Aber das stammt noch aus Blockly Zeiten. Durch die "any-Abfrage" im JS wird es nicht mehr nötig sein. Ich kommentiere das mal aus.

    Zitat

    ...und dann im Auszug Log: #31 javascript.0 2018-07-09 13:00:26.665 info script.js.common.Garagentor_NFC_Java: hm-rpc.2.000218A9916FDA.3


    Das kommt nur wenn die IF-Bedingung "true" ist, denn nur dann werden die Befehle in den {} ausgeführt.

    War jetzt falsch geschrieben. Ja, nach dem if passiert schon was. Aber nicht das was es soll. Laut JS soll der State vom der Schaltsteckdose Test auf true gesetzt werden. Das passiert aber nicht.

    Code
    if ( NFC == "305247091" ) {
    setState("hm-rpc.2.000218A9916FDA.3"/*Schaltsteckdose test:3*/, true, 100);//schaltet Aktor in 200 Millisekunden ein
    setStateDelayed("hm-rpc.2.000218A9916FDA.3"/*Schaltsteckdose test:3*/, false, 1000, true);//schaltet Aktor in 1 Sekunde aus und aktiviert Planung
    setStateDelayed('mqtt.0.domoticz.in', ' ', 1000);//setzt den Wert in domoticz.in auf Null in 1 Sekunde
    log("hm-rpc.2.000218A9916FDA.3");

    Ich sehe hier keinen Fehler. Aber warum funkt es dann nicht?

    Und noch eine Frage. Wie kann ich in der if Abfrage weitere IDs hinzufügen? (Syntax) Sind ja schließlich ein paar mehr Chips, die das steuern sollen.

    Zuerst das einfache:

    JavaScript
    if ( NFC === "123" || NFC === "456" || NFC === "789" )

    solange die Bedingungen in den {} für alle gleich sein sollen?

    Bei Zeile 2 hast du die falsche Syntax. "setState" erlaubt keine Verzögerung

    Zitat

    setState(id, state, ack, callback);

    also nur setState("hm-rpc.2.000218A9916FDA.3", true);

    mit Verzögerung musst du "setStateDelayed" benutzen.

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    Korrigiert: Weiter geht´s

    Danke , auf die Pipe bin ich gar nicht gekommen.

    Laut log erscheint die ID 305247091 und im nächsten Schritt wird

    xmlrpc -> setValue ["3",null,true] SWITCH_VIRTUAL_RECEIVER

    gefolgt vom:

    Error: XML-RPC fault: Invalid parameter or value

    und genau darum passiert eben nix.

    Wenn ich in Objekte unter dem Schaltaktor:3 den State von Hand auf True setze, geht der Aktor an. Also stimmt wohl die korrekte Übergabe der Daten an State nicht.

    Zumindest sieht man im Ablauf, dass sowohl true als auch false gesetzt werden sollen.

    Mühsam ....

    Zitat von Ati

    Mühsam ....

    Vor allen Dingen wenn man keine Homematic hat... ;)

    ...aber ich glaube ich habe den Fehler. Versuche mal setState("hm-rpc.2.000218A9916FDA.3.State", true);

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    Ach nee. ;)

    Also ich würde das mal anders formulieren. Bei mir gibt es fast ausschließlich Homematic bzw. Homematic IP. Das allein schon vor dem Hintergrund, dass ich in jedem Fall eine gewohnte Bedienung brauche (hier ist er wieder der WAF) und aber auf der anderen Seite ein von den Grundfunktionen her sicher funktionierendes und multifunktionales Offline-System haben will. Und welches System kann das besser?

    Dass mit iobroker die Tür zum online aufgestoßen werden kann, was mit HM IP zum teil ja auch ginge, ist Nebenprodukt. iobroker stellt für mich eine große Möglichkeit dar. Mein wichtigstes Anliegen war und ist die Visualisierung.

    Nur, bevor das so richtig umgesetzt wird bin ich immer noch bei Baiscs in der Programmierung - siehe das hier.

    Vom System her ist es eine virtuell laufende CCU2 auf einem RPi3. Zusätzlich ist dort ein iobroker mit drauf, der aber perspektivisch auf einen Server umzieht bzw. dort schon exisitert.

    Aus meiner Sicht ist ein großes Thema die Multifunktionalität. Um das Sauber hinzubekommen muss man alle parallel liegenden Zweige einer Logik so verknüpfen, dass jede Funktion zu jeder Zeit funktioniert, was bekanntermaßen nicht einfach ist.

    Hier beim Garagentor, welches dann via NFC sich öffnen lassen soll, liegen einerseits der Taster des Tors, der direkt an der Steuerelektronik des Motors angeschlossen ist, die Systemfernbedienung des Garagentores und ein Schaltaktor aus dem Homematic IP System parallel. Bedient werden kann das Ganze nun wieder von mehreren Stellen aus. Klar, am Taster an der Tür und mit der Systemfernbedienung. Wenn das nicht wäre- wäre der Hausfrauenstress programmiert. Für mich gibt es eine HM IP Fernbedienung im Auto und Tinymatic auf dem Handy. Mit Tinymatic lässt sich alle an der CCU angelernten Geräte bedienen. Und natürlich gibt es den iobroker.

    Insofern ist Deine Aussage

    Zitat

    Vor allen Dingen wenn man keine Homematic hat... ;)

    nicht ganz zutreffend, oder Du wolltest eigentlich was anderes sagen. Egal. Du hilfst mir wirklich sehr und ich bin echt dankbar dafür.

    Habe den Code jetzt mal eingekürzt. Wenn die Juniors ausgeschlafen haben gegen 11.00 :) , dann dürfen sie "chippen"

    Code
    setState("hm-rpc.2.000218A9916FDA.3.State", true);//schaltet Aktor ein
    setStateDelayed("hm-rpc.2.000218A9916FDA.3.State", false, 1000, true);//schaltet Aktor in 1 Sekunde aus und aktiviert Planung für nächste Aktivierung

    besser so?

    Jepp, dass sieht gut aus.

    bzgl. "Mühsam": War eigentlich auf mich gemünzt, da es auch für mich schwer ist, sich da so ganz ohne alles einzuarbeiten. Gerade wenn man bedenkt, dass ich vom Ergebnis keinerlei Nutzen habe (ist halt doch einfach schöner wenn man es selbst irgendwie gebrauchen kann). Das ist aber völlig Ok so, sonst würde ich auch nicht helfen und ist nicht der Hauptgrund, sondern einfach nur der, dass ich im Broker oder sonst wo nicht einfach mal nachschauen kann, oder wie beim "Koiteich" mit DS18B20-Sensoren etwas emulieren und selbst probieren kann ;)

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    Na dann machen wir mal weiter.

    Code
    javascript.0    2018-07-10 09:57:13.080    warn    State "hm-rpc.2.000218A9916FDA.3.State" not found
mqtt.0    2018-07-10 09:57:12.089    info    Client [ESPClient1] subscribes on "mqtt.0.domoticz.out"
javascript.0    2018-07-10 09:57:12.086    info    script.js.common.Garagentor_NFC_Java: hm-rpc.2.000218A9916FDA.3

    Das scheint noch nicht zu passen.

    schimmer-media.de/index.php?attachment/3345/

    Hier mal die Instanz der Schaltsteckdose.

    Es ist ein Frage der Schreibweise.

    Code
    setState("hm-rpc.2.000218A9916FDA.3.STATE", true);//schaltet Aktor ein

    setStateDelayed("hm-rpc.2.000218A9916FDA.3.STATE", false, 1000, true);//schaltet Aktor in 1 Sekunde aus und aktiviert Planung für nächste Aktivierung

    STATE muss Großbuchstaben haben. Damit funktioniert es nun teilweise. :)

    Was nicht funktioniert, bei einem Chip kann man wieder und wieder aktiveren, also einwandfrei. Bei anderen funktioniert das nicht. Dort funktioniert es nur einmalig. Aber jetzt aus der Ferne etwas schwierig zu beurteilen. Auf jeden Fall wieder ein großer Schritt zur Lösung hin.

    Zitat von Ati

    STATE muss Großbuchstaben haben. Damit funktioniert es nun teilweise.

    Wollte ich gerade schreiben. Die Datenpunkte sind case sensitiv :)

    Müsste man dann mal sehen ob sich auch der Value des NFC korrekt ändert/bzw. die Aktualisierung funktioniert.

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    So. Nun funkt es richtig - na fast. Alle Chip tun jetzt was sie sollen. Das Problem ist folgendes. Wenn eine Verzögerung von nur 1 Sekunde zum Ausschalten führt, erkennt der Reader erneut den gleichen Chip und schaltet erneut ein. Das führt dann dazu, dass das Garagentor anhält. Nochmalige Erkennung schließt es wieder usw..

    Ich habe die Verzögerung jetzt auf zwei Sekunden gestellt. Das kommt jetzt in etwa hin.

    Bissel störend sind auch ab und zu Verzögerungen.

    Code
    javascript.0    2018-07-10 15:26:14.498    info    script.js.common.Garagentor_NFC_Java: hm-rpc.2.000218A9916FDA.3
javascript.0    2018-07-10 15:26:14.498    info    script.js.common.Garagentor_NFC_Java: 2798486467
javascript.0    2018-07-10 15:26:13.403    info    script.js.common.Garagentor_NFC_Java: hm-rpc.2.000218A9916FDA.3
javascript.0    2018-07-10 15:26:13.402    info    script.js.common.Garagentor_NFC_Java: 2798486467
mqtt.0    2018-07-10 15:26:04.348    info    Client [ESPClient1] subscribes on "mqtt.0.domoticz.out"
javascript.0    2018-07-10 15:26:04.311    info    script.js.common.Garagentor_NFC_Java: hm-rpc.2.000218A9916FDA.3
javascript.0    2018-07-10 15:26:04.310    info    script.js.common.Garagentor_NFC_Java: 2798486467

    Das ist immer dann, wenn

    Code
    mqtt.0    2018-07-10 15:26:04.348    info    Client [ESPClient1] subscribes on "mqtt.0.domoticz.out"

    kommt. Danach funktioniert es wieder. Der nodeMCU ist optimal mit WLAN versorgt. Störende Geräte sind nicht in der Nähe, außer der Node stört selbst den Reader.

    Ich vermute mal du hast eine NodeMCU, Reader und eine Relaisplatine als Hardware im Einsatz? Die hängen alle an einer Stromversorgung die genügend "Saft" liefert?

    Eigentlich sollte er nur einmalig beim hochfahren "subscriben". Er meldet sich dabei am MQTT-Server/Broker quasi an und sagt "Hey Server, wenn neues von 'xyz' kommt schieb mal rüber". Dabei stockt es einen kurzen Augenblick (ist/wäre auch nicht tragisch, ist ja nur einmalig beim hochfahren des Clients).

    Also entweder startet er öfters durch (Stromversorgung) oder verliert das WLAN-Signal.

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    Du vermutest fast richtig. Fast.

    Es ist eine NodeMCU und ein Readermodul. Diese beiden hängen an einen 2 Ampere USB-Netzteil. Nach meinen bisherigen Erfahrungen mit dem Netzteil gab es in anderen Konstellationen nie Stress. Aber einen Test ist es auf jeden Fall wert.

    Relaisplatine? So was schnödes verwenden ich nicht. Relais sind mir zu laut. :D

    In diesem Zusammenhang brauch ich auch keine Ausgabe direkt, sondern die NodeMCU liefert an den iobroker Info und dort wird auf einen Homematic IP-Aktor umgeleitet. Der Homematic-Aktor wiederum wird noch von anderen Stellen aus bedient.

    Ich check das mal mit dem Netzteil.

    Ist der Reader ein RC522? Der hat ~30mA (beim Lesen), dass verkraftet die NodeMCU am 3.3V-Pin, und da ist ein 2A-Netzteil auch oversized, würde ich dann eigentlich ausnehmen.

    Du könntest auch mal testweise den Reader abklemmen (nur wg. Störungen), einen x-beliebigen Pin als "Switch" deklarieren und den dann kurz gegen Masse als Schaltsimulation brücken. Falls das "Subscribe" nun ausbleibt, könnte sich doch ev. die RFID-Antenne (gerade beim Lesevorgang) mit dem WLAN in die Quere kommen.

    Relais sind aber gar nicht schlecht. Meine beiden Messgeräte sind immer kostenlos dabei und einsatzbereit. Bei z.B. einem Optokoppler musst du messen (sofern halt keine Anzeige vorhanden ist), ein Relais höre ich aber klicken :)

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    ich weiß, dass man das klicken hört, sofern man nicht schon altersschwerhörig ist ;)

    Dennoch verwende ich, wenn es geht, elektronische Lastrelais. Gibt es heutzutage ja alles fertig. Nicht mehr so wie früher mit Diac, Thyristor, Triac, Power MOS.

    Ich schau nachher mal welcher Reader das ist. Weiß ich grad nicht aus dem Kopf - na Du weißt schon - Alter, vergessen, ..... :D

    Versorgst du den vom 3.3V-Pin der NodeMCU? Der scheint ~150mA zu brauchen, dass könnte eng werden.

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

    Ja, ich versorge den über die NodeMCU. Habe gestern mal den Strom gemessen (versucht). Die Stromaufnahme schwankt ziemlich zwischen 6 und 16 mA im Ruhezustand. Eigentlich sonderbar. Im Lesemodus ist keine signifikante Erhöhung sichtbar. Kann sein, dass das in zu kurzer Zeit geschieht. Ich schau mal, ob ich einfach mal einen Pufferelko in die Leitung reinsetze. Die Anschlussleitung habe ich verlängert, um Störungen durch Funkfelder mal auszuschließen.

    Laut Datenblatt zieht er Continuous total current consumtion typ 91 mA (max 140mA)

    Der analog supply current ist mit 6 mA wie gemessen. Also passt schon. Laut Datenblatt hängt der Totalstrom von der Firmwareversion ab (interner Takt). Alternativ versorge ich dann wohl mal den Reader separat. Ein altes Computernetzteil mit 3,3 Volt und 20 Ampere sollte reichen (Scherz).

    Wenn das die Lösung sein sollte, kann dann ein kleiner Step Down Wandler sein Werk tun.

    Falls es mit besserer Stromversorgung funktioniert, kannst du auch anstelle des Step-Down einfach zwei Dioden (bspw. die beliebte 1N4007) in Reihe davor schalten. Jede Diode hat einen Spannungsabfall von ~0.7V:

    5V - 2* 0.7V = 3.6V

    Die letzten Worte vor dem Weltuntergang: "...das ist technisch völlig unmöglich..."

    aktuelle Projekte: <<< Magic Mirror +++ RMS +++ Wetterstation +++ Somfy Fernbedienung >>>

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden