Posts by joh.raspi

    Das ist dann aber doch kein Lebenszeichen sondern eine Empfangsbestätigung.


    Sichergehen dass der Raspi die Nachricht auch bekommen hat ist kein Problem.


    Bei den bisherigen Beispielen werden die Daten alle per HTTP verschickt, dabei
    antwortet der Server immer mit einem bestimmten HTTP Status Code im Header.
    Der Status Code "200 OK" beudeutet im Normalfall dass der Server die Daten bekommen
    hat und auch etwas damit anfangen kann.


    Im Fehlerfall wenn beispielsweise was mit der URL nicht stimmt, ein falscher Parameter, API key oder
    ähnliches angegeben wurde, der Server gerade zu ausgelstet ist, .. antwortet
    er mit einem Status Code ungleich 200.


    Hier der Teil in dem ich dem ich den Status Code prüfe:
    https://github.com/8n1/ESP8266…/arrestdb_request.lua#L63
    Und hier das mit den Wiederholungen im Fehlerfall:
    https://github.com/8n1/ESP8266…blob/master/init.lua#L160

    Ja, würde aber wenn der ATTiny das (per Watchdog) selber machen muss einen erhöhten Stromverbrauch im Standby bedeuten.
    Kann aber gar nicht sagen wie hoch genau. ich schätze so 20µA bis maximal 50µA.


    Genau für diesen Zweck hab ich aber auf der Platine (auch schon bei der ersten) die Möglichkeit vorgesehen ein DS3231 RTC Modul anzuschließen
    und den ATtiny damit aufzuwecken. Damit bleibt der Stromverbrauch im Standby so niedrig wie bisher.
    Zumindest was die belastung der Akkus/Batterien betrifft, die RTC selber braucht ja auch ein bischen Strom wird aber von der Knopfzelle
    die auf dem Modul verbaut ist versorgt. Allerdings ist die irgendwann auch leer sofern es keine Aufladbare ist. Lässt sich aber bestimmt
    auch irgendwie erkennen.


    Hab das aber noch gar nicht ausprobiert und es wird auch noch nicht vom Code unterstützt. Man müsste für die RTC Variante aber nur die ESP Seite
    anpassen, der ATtiny lässt sich jetzt schon über das RTC Modul wecken.


    Einmal pro Stunde aufwecken ist wie ich finde leicht übertrieben. Ich denke bei einem "bin noch am leben" eher an einmal pro Tag oder eigentlich
    sogar >= einmal pro Woche.
    Der eigentlich einzige Grund wieso der Sensor aufhört zu arbeiten ist wegen einem leeren Akku. Da die Akkuspannung aber sowieso mitgeschickt
    wird lässt sich das früh genug erkennen.


    Ich hab inwzischen so gut wie all meine Projekt von NodeMCU/Lua auf die Arduino IDE umgestellt. Meine Sensoren senden die Werte jetzt
    über MQTT an FHEM. Werd den Code demnächst mal aktualisieren.



    Mit ArrestDB ist es jetzt auch schon möglich das ganze lokal laufen zu lassen die Werte in einer Datenbank speichern zu lassen.
    Funkioniert allerdings nicht über MQTT sondern über eine einfache REST API und setzt einen Webserver voraus.


    Im Moment kann man aus folgenden wählen: IFTTT, Pushingbox, Thingspeak und ArrestDB
    Wobei ArrestDB kein Online Service ist sondern ein PHP Skript dass auf meinem Raspi läuft und eine einfache REST API zum lesen und schreiben von Datenbanken bereitstellt.

    Nein ist kein Sonoff TH sondern der ganz einfache.
    Hatte den Link vom TO im Eingangspost gar nicht angeschaut und bin da keiner was bezüglich Strommessung oder so geschrieben hat davon ausgegangen dass ihr alle den einfachen bestellt habt. :rolleyes: Deshalb auch mein letzter Beitrag.


    Bezüglich programmieren schau mal hier: http://www.andremiller.net/con…less-smart-switch-esp8266
    Hier noch die Produktseite vom einfachen Sonoff: https://www.itead.cc/smart-hom…wifi-wireless-switch.html


    Zentris:danke_ATDE::thumbs1: Das CE Zeichen sollte aber zumindset bei den neuen Sonoffs kein Fake sein. Der TO hatte im Eingangspost ja auch schon auf die CE Zertifikate auf der Produktseite verwiesen. Oder denkst du/ihr die sind wirklich Fake?

    Quote


    Quality of the new Sonoff line (TH10, TH16, POW and DUAL) is pretty good and that’s why they recently got the CE mark from the EU.
    http://tinkerman.cat/the-sonoff-pow/

    Meiner noch nicht. Hab aber schon ein bisschen recherchiert.
    Das programmieren scheint ja wirklich sehr einfach zu sein. Über Google findet man denk ich mal sehr schnell alles was man wissen muss.


    Habt ihr die ganzen anderen Sonoffs auch schon entdeckt?
    https://www.itead.cc/wiki/Product
    Https://www.itead.cc/wiki/Sonoff_Smart_Home_Solution


    Zwei die mir öfters untergekommen sind:
    Sonoff Pow
    Wie der normale Sonoff allerdings zusätzlich mit der Möglichkeit die Leistung des Verbrauches auszulesen.


    Oder der(die) Sonoff TH bei dem man noch über einen Klinkenstecker einen Temperatur Sensor (oder je nach programmierung was auch immer) anstecken kann.


    Sonoff Touch sieht aber bspw. auch interessant aus.

    Genau, so hatte ich das "network-online.target" auch verstanden.


    Eine von systemd unabhängige Möglichkeit alle laufenden Prozesse seit dem Start anzuzeigen ist "sudo ps aux".


    Mit systemd geht wohl mit: systemd-analyze (nicht selber getestet)
    http://serverfault.com/questio…execution-tree-of-systemd
    https://www.freedesktop.org/so…/man/systemd-analyze.html


    Also hast du den Autostart per sleep hinbekomen?


    Grad hier noch was interessantes entdeckt:
    https://www.freedesktop.org/wi…re/systemd/NetworkTarget/


    --
    Klar. Google suche nach: "bash zufallszahl"

    Hey Super, dann ist also wikrlich der zu frühe Start das Problem.


    Liegt wohl an dieser Zeile:
    "After=network-online.target"


    Kenn mich damit aber auch viel zu wenig bis gar nicht aus und müsste mich erstmal einlesen und am besten selber testen.
    Beudeutet dass ich euch bei diesem Problem im Moment leider nicht weiterhelfen kann und ihr vorerst auf den Workaround mit dem sleep setzen müsst.
    Ich würd aber sonst einfach mal einen neuen Thread für das Problem mit dem Autostart aufmachen, bin mir fast sicher dass da jemand direkt sagen kann wieso das nicht klappt.


    Quote

    Öhm, keine Ahnung...


    Prüf das doch mal. Er muss auf jeden Fall das sleep die >10min ausführen.


    Grad das Problem mit dem Screenshot gesehen, gut gemacht. Ich hab im Skript der einfachheit halber nur das send_text() eingebaut. Lässt sich ja wie du gemerkt hast sehr einfach beliebig erweitern. :)



    Und ja, Zeilenumbruch in der Antwort klappt mit einem "\n".

    Oh, doch mach ich noch. Das ist wohl irgendwie untergegangen. Gut aufgepasst. Daran sollte der start aber nicht scheitern.


    --
    Gibt's ja nicht :/ Hat er das "sleep" laut "status" nach dem Neustart auch 10 min lang ausgeführt?


    Sieht so aus als hätte er das Skript gar nicht erst gestartet bekommen. Hast du das Skript auch als "pi"(bzw. dem Benutzer unter dem der Client laufen soll) und nicht als root angelegt?

    Code
    ls -la /home/pi/tg/start_telegram.sh
    -rwxr-xr-x 1 pi pi 175 Jän 11 06:05 /home/pi/tg/start_telegram.sh

    Das ist ja blöd. Da habt ihr beide ja scheinbar genau das gleiche Problem.
    Ich hätte das nicht gepostet wenn es bei mir nicht so funktionieren würde.


    Hier mal der letzte Teil meiner /var/log/syslog:


    Der beendet sich und startet immer wieder brav. (Der erste Eintrag ist drin weil ich da nochmal was geteset hatte.)


    Um zu testen ob der Client aus irgendeinem Grund nicht doch zu früh gestartet wird könnt ihr den Client ja mal mit einem sleep verzögert starten. So hab ich ihn auch über die /etc/rc.local gestartet bekommen.


    Geht bestimmt auch anders aber ich hab dazu nochmal ein kleines Skript erstellt das nichts weiter macht wie den Client verzögert zu starten:

    Bash
    #!/bin/bash
    # 2 minuten warten
    sleep 120
    # telegram client starten
    /home/pi/tg/bin/telegram-cli -s /home/pi/tg/fwd.lua -d -E -R -P 54321 -W


    Das Skript hab ich im telegram Verzeichnis gespeichert
    und ausführbar gemacht:

    Code
    chmod +x /home/pi/tg/start_telegram.sh


    Anschließend die Unit angepasst dass sie nicht mehr den Client direkt startet sondern das Skript:

    Code
    ExecStart=/home/pi/tg/start_telegram.sh


    Dann ein Neustart und wieder mit "sudo systemctl status ..." getestet.


    Achja, Ich hab ganz vergessen dass bisher immer alle Ausgaben auf die Konsole aufgrund des "-D" deaktiviert waren. Hab diesen Parameter im Skript jetzt mal weggelassen und sollte einiges mehr ausgegeben werden über "sudo systemctl status ...".
    Das Ausgaben sollten auch in der /var/log/syslog auftauchen.


    EDIT: Option -d ergänzt.

    Ob du den Port brauchst kommt darauf an wie du den Client verwendest. Für den Autostart ist er nicht relevant. In diesem Tutorial wird aber benötigt damit der Telegram Client antworten kann.


    Kanns du den Client so von der Kommandozeile aus starten?

    Code
    /home/pi/tg/bin/telegram-cli -s /home/pi/tg/test3.lua -d -D -E -R -P 54321 -W

    Hi,


    Sorry, bin bis gestern nicht wirklich dazu gekommen das mit dem Autostart nochmal mit einem frischen "Jessie" zu testen.


    Also dass der Autostart über die /etc/rc.local jetzt zumindest so wie beschrieben nicht mehr klappt liegt scheinbar daran dass die /etc/rc.local bei Jessie früher ausgeführt als bei Wheezy. Noch bevor das Netzwerk bereit ist und das führt dazu dass sich der Telegram Client nach dem start direkt wieder beendet.


    Man müsste da jetzt anfangen zu tricksen aber es ist sicher am besten den Autostart gleich mit einer systemd Service Unit zu machen.
    Ist auch recht schnell erledigt und klappt hier im test genau wie es soll.
    Ich gehe jetzt davon aus dass ihr ein (aktuelles) Jessie verwendet.


    1. Neue Unit Datei unter /etc/systemd/system/ anlegen...

    Code
    sudo nano /etc/systemd/system/telegram-client.service


    ... und mit folgendem Inhalt füllen: (Unter [Service] Pfade und der Benutzer unter dem der Client laufen soll anpassen)


    2. Sicher gehen dass die Rechte der Unit richtig gesetzt sind:

    Code
    sudo chmod 664 /etc/systemd/system/telegram-client.service


    3. Bevor die Unit jetzt im System verankert wird testen ob sie überhaupt richtig startet:

    Code
    sudo systemctl start  telegram-client.service


    Code
    sudo systemctl -l status  telegram-client.service


    Sieht die Ausgabe in etwas so aus hat es geklappt:

    Code
    ● _telegram-client.service - Telegram Client Daemon
      Loaded: loaded (/etc/systemd/system/telegram-client.service; enabled)
      Active: active (running) since Mit 2017-01-11 06:11:23 UTC; 1s ago
    Main PID: 616 (telegram-cli)
      CGroup: /system.slice/__telegram-client.service
              └─616 /home/pi/tg/bin/telegram-cli -s /home/pi/tg/fwd.lua -d -D -E -R -P 54321 -W
    Jän 11 06:11:23 raspberrypi systemd[1]: Started Telegram Client Daemon.


    4. Passt soweit alles kann die Unit aktiviert werden:

    Code
    sudo systemctl enable telegram-client.service


    Abschließend ein Neustart und nochmal prüfen ob der Client auch wirklich läuft:

    Code
    sudo reboot


    Code
    sudo systemctl -l status  telegram-client.service


    Fertig.


    [hr]

    Quote


    schicke ich (User Joh) den Wortlaut "ping", kommt Pong zurück, schicke ich "!pingel" sollte eigentlich "Pongelpongelpong..!" zurück kommen, es kommt aber nur "Unbekannter Befehl!"


    Nee, das passt so. So hast du das programmiert. :)
    Die ganzen Bedinungen sind ja mit einem "else if" verbunden somit gwinnt immer die erste Bedinung.
    Im Falle von "Joh":

    Code
    if [[ $user == "Joh" ]]; then


    Alle anderen kommen gar nicht mehr zum zug:

    Code
    elif [[ $user == "Joh" ]] || [[ $user == "Marc" ]]; then

    Hi,


    Wenn du damit besser zu recht kommst kannst du das ganze auch in PHP machen:


    Allerdings ist das Skript sicher verbesserungsfähig. Beispielsweise ist der externe Aufruf von netcat (nc.traditional) unnötig und sollte besser mit PHP Boardmitteln erledigt werden. Kenn mich damit aber nicht so gut aus und hab deshalb einfach wie im Shellskript auch netcat verwendet um dem laufenden Telegram Client Befehle zu übergeben.


    [hr]

    Quote

    Gibts auch ne Möglichkeit die befehle die für beide User zulässig sind nur einmal ins script einarbeiten zu müssen?


    Ja, einfach in Funktionen auslagern.


    Quote

    Da schmeisst er mir dann nen Syntaxfehler...


    Die Bash kennt kein "or", da verwendet man "||"

    Code
    if [[ $user == "Joh" ]] || [[ $user == "Marc" ]]; then


    Und hier fehlt noch der abschließende Anführungsstrich

    Code
    "!ping!)


    Code
    "!ping!")

    Hi,


    Welcher Pfad hat sich denn geändert?


    Das mit den unterschiedlichen Benutzern würd ich wie folgt machen:


    Als erstes die fwd.lua so umbauen dass sie nicht nur die Nachricht sondern auch den Absender and das Shellskript übergibt:
    Dazu diesen Teil:

    Code
    --------------------------------------------
     -- Nur Nachrichten vom Benutzer Joh aktzeptieren
     --if (msg.from.print_name == 'Joh') then
       --os.execute (string.format("/home/joh/telegram_cli/tg/msg-parser.sh \"%s\" &", msg.text))
     --end
     --------------------------------------------


    durch diesen ersetzten:

    Code
    --------------------------------------------
     -- Skript im Hintergrund starten, Benutzername und Nachricht als Parameter übergeben
     os.execute (string.format("/home/joh/telegram_cli/tg/msg-parser.sh \"%s\" \"%s\" &", msg.from.print_name, msg.text))
     --------------------------------------------


    Und das Shellskript in etwa so anpassen:


    Somit kann "Joh" die Befehle "Ping" und "uptime" verwenden. Und "Marc", "Ping" und "date". Alles andere führt zu "Unbekannter Befehl!".
    Andere/unbekannte Benutzer bekommen direkt ein: "Benutzer: $user nicht autorisiert!" zurück.


    Ich hoffe das reicht dir um weiter zu kommen. Falls ich was genauer erklären soll einfach fragen.


    Ps: Das mit dem Autostart werd ich am Abend mal mit einem frischen System testen.

    Hi,


    Hab mal ein paar Bilder vom Schaltplan und Layout sowie einen Arduino Sketch angehängt.


    Das LCD wird mit der LiquidCrystal Lib von Adafruit angesteuert, die Idee hinter dem Sketch ist alle Funktionen welche die Lib zur verfügung stellt über eine einfache HTTP API verfügbar zu machen.
    Funkioniert soweit auch alles allerdings ist der Sketch nur schnell schnell zusammengehackt und noch nicht "fertig". Das letzte was ich gemacht habe war ein minimalistisches Webinterface um bequem die einzelnen Funktionen testen zu können. Was, neben generell nochmal alles überarbeiten, noch fehlt ist das Interface um eigene Zeichen zeichnen/definieren zu können, klappt aber mit einer lokalen .html auf dem Desktop schon.


    Um den Sketch kompilieren zu können braucht man neben der LiquidCrystal Libarary auch noch die ArduinoJson Library. (Kann beides über den "Library manager" installiert werden)


    Anpassen muss man nur die Zugangsdaten zum Wlan Netzwerk (sta_ssid und sta_password).


    Während sich der ESP dann mit dem Wlan Netzwerk verbindet wird "Connecting to AP" auf dem LCD angezeigt, ist er verbunden "Ready.".
    Anstatt einer statischen IP verwende ich MDNS um das LCD im Nerzwerk zu finden. Erscheint das "Ready" kann man sich dank MDNS über http://lcd.local dem LCD verbinden und es erscheint das erwähnte Webinterface zum testen. (Voraussetzung für MDNS: https://github.com/esp8266/Ard…ies/ESP8266mDNS/README.md)


    Werd mit dem ganzen aber erst bis frühestens in 2 Wochen weiter machen. Bis dann hab ich auch die Platinen.
    Das ganze ist aber nur die Umsetzung eine ersten Idee für so ein Wlan LCD auf ESP8266 Basis....