Neues Modul: ESPEasy [war: ESPEasy ohne MQTT]

[dev0]

nach Reset, schalten die Relais nicht wieder in die Pos vor Reset

Ob ein Relais nach dem Einschalten des ESPs immer ein- oder ausgeschaltet seinen soll kannst Du mit einer Rule auf dem ESP bestimmen.

Damit der Zustand der Relais nach nach aus/einschalten wiederhergestellt wird, kannst Du ein Notify verwerden, dass auf das presence Reading triggert: absent -> on/off der gpios in einem eigenen Reading speichern, present -> Deine Readings wieder auslesen und den ESP setzen. Das funktioniert allerdings nur dann, wenn das Interval der Presence Detection kurz genug ist um die Abwesenheit zu erkennen. Bei einem Reset wird das schwierig.

Wenn es auch bei einem Reset und unabhängig von FHEM funktionieren soll, dann mußt Du das in die ESPEasy Software implementieren -> Den Zustand immer ins EEprom schreiben und beim Booten auslesen und setzen. Schreibzyklen des EEProms sind aber begrenzt. 100.000(?)

Btw: die Presence Detection des Moduls hat noch eine Macke: nach einem FHEM Neustart gehen alle ESPs auf present, auch wenn sie sich nicht melden. Das fixe ich am Wochenende in einer neuen Version.

[Peter_64]

Hallo Dev,
alles klar vielen Dank für den Tipp
Gruß

[freddy_mabuse]

Hallo,

ich muss mich vorab als Anfänger der Materie outen.
Ich habe das Thema FHEM zum Anlass genommen, mich in die Heimautomatiesierungsmaterie ein wenig einzuarbeiten.

Stand der Dinge:
FHEM auf raspberry - läuft
3 Funksteckdosen + LD382-Wifi-LED-Controller - läuft

H801-Wifi-LED-Controller mit ESPEasy geflasht - läuft
Steuerung via http-command - läuft

Code Auswählen Erweitern

http://<ESP IP address>/control?cmd=PWM,<pin>,<level>

Pin    Function
15    Output red
13    Output green
12    Output blue
14    Output white 1
04    Output white 2

<level> 0..1024 (zumindest scheint es die Range zu sein)

Ich würde gerne wie schon beim LD382 auch hier ein Element mit Colorpicker nutzen.

Code Auswählen Erweitern

attr espeasy-wifi-led webCmd RGB
attr espeasy-wifi-led widgetOverride RGB:colorpicker,RGB

1. Frage/Problem:
Wie kann ich die Werte "RGB,brightness,hue,saturation" aus dem colorpicker-Modul in die benötigten Werte für den http-Aufruf (0..1024) der einzelnen Farben RGBW umrechnen)?

2. Frage
Lässte sich die Kommunikation (ja, eher einseitig) mit dem "34_ESPEasy.pm" realisieren oder ist das Overkill?
Im Modul Wifilight sind nur die properitären Ansteuerungen der einzelnen Geräte. Gibt "98_HTTPMOD.pm" noch etwas zur Lösung her?

Ich bin für jede Anregung und Hilfe dankbar. Meine Programmierkentnisse begrenzen sich leider eher auf das Abtippen von Code.
Bei Erfolg sollte es möglich sein, alle (chinesischen/selbstbau/etc) RGBW-Wifi-ESP8266-Clones nach Flashen mit ESPEasy mit der selben Methode ansteurn zu können.

So long.

[dev0]

Meiner Meinung nach ist ESPEasy nicht wirklich geeignet einen RGBWW Controler anzusteuern, zumindest nicht ohne passendes Plugin. Dieses Projekt hat beispielsweise wesentlich mehr Potenzial dazu.

Wie kann ich die Werte "RGB,brightness,hue,saturation" aus dem colorpicker-Modul in die benötigten Werte für den http-Aufruf (0..1024) der einzelnen Farben RGBW umrechnen)?

Vermutlich so: Die (hex-rgb?) Werte in die 3/5 Kanäle splitten, in dezimal Werte umwandeln und auf den Range von 0..1023 skalieren. Diese Werte dann einzeln an Deinen Controller schicken. Dazu benötigst Du ein userReading und etwas Perl Code. Oder Du schreibest ein Plugin für die ESPEasy Software, das mit RGBWW Werten zurecht komt.

Lässte sich die Kommunikation (ja, eher einseitig) mit dem "34_ESPEasy.pm" realisieren oder ist das Overkill?

Ja. Den overkill sehe ich nicht.

Ohne Programmierkenntnisse wirst Du es mit einem Perl Framework, wie FHEM, schwer haben.
Ob Du mit HTTPMOD etwas anfangen kannst, mußt Du selbst entscheiden, Fragen dazu bitte im passenden Bereich/Thread oder im Anfängerbereich stellen.

[dev0]

Nun, der Usecase ist der Gleiche wie bei 'allowedIP'.
Allerdings ist es bei >4 Devices deutlich weniger fehlerträchtig eine Blacklist zu führen.

Kann ich nicht nachvollziehen. Zeige das mal bitte anhand eines Beispiels auf.

Da Du darauf bisher nicht geantwortet hast, habe ich das Feature so implementiert, wie ich es für sinnvoll erachte:
Das Attribut 'allowedIPs' erlaubt weiterhin einzelne IPs und/oder Subnetze und verbietet alles Andere. Das neue Attribut 'deniedIPs' verbietet einzelne IPs und/oder Subnetze und verbietet auch Überschneidungen mit 'allowedIPs'.

So kann man beispielsweise den Zugriff auf zwei Class-C Netze beschränken, einer IP und einem Subnetz von 4 Hosts darin den Zugriff verweigern:

Code Auswählen Erweitern


attr bridge allowedIPs 172.16.0.0/23
attr bridge deniedIPs 172.16.0.10,172.16.10.32/30


[dev0]

Version 0.64 liegt auf Github...

- fixed faulty presence detection after FHEM restart
- close open tcp session immediately if ESP is going to deep sleep (EPSEasy bug?)
- added attribut deniedIPs

[PeMue]

Ich habe mal mit der ArduinoJson Library 5.6.7 kompiliert, konnte aber leider noch nicht testen (siehe Anhang).

dito für ESPEasy R142 (siehe Anhang, die eingestellten SPIFFS Größen weiß ich leider nicht mehr).

[dev0]

Sind die Images kompatibel zu den "Originalen", die im ESP Easy Wiki angeboten werden (esp8266.nu / letscontrolit.com)?
Wenn ich mich nicht irre und man beim Kompilieren/Upload eine andere SPIFFS Größe angibt, dann ist nach einem (OTA-)Update die Config weg. Oder täusche ich mich?

[JoWiemann]

Version 0.64 liegt auf Github...

Hallo,

ich bekommen folgenden Fehler bei einem reload:

Code Auswählen Erweitern


Not enough arguments for main::ESPEasy_isAuthenticated at /usr/share/fhem/FHEM/34_ESPEasy.pm line 606, near "})"
BEGIN not safe after errors--compilation aborted at /usr/share/fhem/FHEM/34_ESPEasy.pm line 1717.


PS: Nach einem zweiten reload ist alles Ok! Wunder über Wunder

[dev0]

Du hast nicht neu gestartet (wie nach einem normalem FHEM Update), sondern nur reload '34_ESP...' ausgeführt?

[JoWiemann]

Du hast nicht neu gestartet (wie nach einem normalem FHEM Update), sondern nur reload '34_ESP...' ausgeführt?

Ja, mache ich in meinem Testsystem fast immer, wenn ich ein einzelnes Modul aktualisiere.

Grüße Jörg

[dev0]

Ich vermute, dass ich dieses Verhalten, durch die Deklaration aller Subs am Anfang des Moduls, vermeiden kann. In der nächsten Modul Version sollte es somit nicht mehr auftreten.
Danke für den Hinweis.

[SusisStrolch]

Da Du darauf bisher nicht geantwortet hast, habe ich das Feature so implementiert, wie ich es für sinnvoll erachte:
Das Attribut 'allowedIPs' erlaubt weiterhin einzelne IPs und/oder Subnetze und verbietet alles Andere. Das neue Attribut 'deniedIPs' verbietet einzelne IPs und/oder Subnetze und verbietet auch Überschneidungen mit 'allowedIPs'.

Sorry, war auf Dienstreise und deshalb ein wenig eingeschränkt...
Prima - genau so hatte ich mir das gewünscht/vorgestellt!

[PeMue]

Sind die Images kompatibel zu den "Originalen", die im ESP Easy Wiki angeboten werden (esp8266.nu / letscontrolit.com)?
Wenn ich mich nicht irre und man beim Kompilieren/Upload eine andere SPIFFS Größe angibt, dann ist nach einem (OTA-)Update die Config weg. Oder täusche ich mich?

Hm, ich habe nirgendwo die SPIFFS Größe angegeben gesehen, daher habe ich immer mit der größten Größe kompiliert. Oder sollte man da die kleinste nehmen? Ehrlich gesagt, ich habe keine Ahnung ...

Gruß PeMue

[Muschelpuster]

Super Modul! Ich bin auch durch Zufall über dei Möglichkeiten vom ESP8266 gestolpert und warte nun sehnsüchtig auf meine Module. Aber ich hatte ja, nachdem ich diese Ecke gefunden habe, erst einmal 22 Seiten zu lesen 
Schön, dass ich nun nicht noch MQTT meinem PI antun muss oder dafür einen weiteren PI brauche.

Was hälst du von einem Wiki Eintrag?

Eigentlich nichts, da viele Wiki Beiträge nach einer gewissen Zeit nicht mehr aktuell sind und es keiner merkt. Eine ausführliche commandref sollte das aber abdecken.

Na ja, ich habe auf den letzen 22 Seiten auch viel gelesen, was nicht mehr aktuell ist. Jeder, der am Wiki-Artikel scheitert, wird sich irgendwo melden und so ggf. auch eine Anpassung des Wiki-Artikels vornehmen oder durch seinen Hilferuf auslösen.
Ich sehe den Vorteil eines Wiki-Artikels gegenüber der commandref darin, dass man etwas links und rechts vom Modul schauen kann, besser auf die Hardware eingehen kann, Bilder einbinden kann etc.
Aber das sollte natürlich nicht Aufgabe der Entwickler sein - die sollen das machen, was ihnen Spaß macht - coden! Aber alle Nutznießer der Module halte ich für aufgerufen, dem Projekt etwas zurückzugeben und am Wiki zu arbeiten, sobald sie ein Modul / eine Lösung so gut verstanden haben um es zu erklären.
Ist natürlich nur meine Meinung 

dokumentierte Grüße
Niels