Bedarf/Interesse an erweitertem Netatmo Modul?

[tuxbox]

Hallo zusammen,

nur eine kurze Anfrage, ob es evtl. Interesse an einem "erweiterten Netatmo" Modul gibt.
Ein rudimentäres Netatmo Modul zur Abfrage von public station Daten ist ja zwar schon vorhanden,
aber ich brauchte ein sehr viel weitergehendes System, das
- Alle Daten meiner eigenen Netatmo Module (Innenhauptmodul, Zusatzinnenmodule, Außenfühler etc.)
  erfasst: wie Sonometer, CO2-Gehalt, RF Empfangsstärke, Batteriestand etc. etc.
- FHEM nicht durch die Anfragen am externen netatmo-Server "belastet" oder gar blockiert
- die Möglichkeit bietet, am Netatmo-Thermostat (f. Gastherme) Einstellungen vorzunehmen
   (hier habe ich bei mir z.B. über Abfrage der valvepositon-Stände der MAX HTs die Möglichkeit, manuell
   bei Notwendigkeit die Therme zu starten (die sonst nur über eigenes Thermostat das Wohnzimmer
   regeln kann) .. oder bei offenen Fensterkontakten die Therme auf Frostabschaltung
   zu setzen etc. etc.)

Das ganze läuft über einen Systemdämon, der die Kommunikation mit dem netatmo-Server im Hintergrund
übernimmt und einem ständig aktualisierte (Polling abgestimmt auf Daten hierzu vom Server .. ca. alle 10 Minuten,
je nach Serverrückmeldung) Daten zur Verfügung stellt und Befehle entgegennimmt und Statusmeldungen zu
Aufträgen bereitstellt.
Hierzu übernimmt er auch die Token und OAuth Verwaltung zu Netatmo hin und fängt Kommunikationsprobleme
ab (z.B. stimmen hin und wieder die übermittelten tokenexpires Werte nicht).
Dadurch kann das System nicht durch Kommunikationsschwierigkeiten zu netatmo blockiert werden, man
hat optimal aktuelle Werte und einen Zugriff auf hohem Abstraktionslevel.

Das ganze läuft bei mir ohne Probleme und inzwischen hoch performant (siehe anderes Posting). Allerdings ist das ganze bei mir noch
sehr an meine Heiminfrastruktur angepasst.

Sollte jedoch allgemeiner oder vermehrter Bedarf/Interesse bestehen, würde ich das ganz noch etwas aufbereiten
und hier zur Verfügung stellen.

Viele Grüße,
Frank tuxbox

[justme1968]

zum interesse bei anderen kann ich natürlich nichts sagen aber zum aktuellen modul.

ich würde es nicht als rudimentär bezeichnen und es ist nicht auf public stations beschränkt. es kann alle messwerte von eigenen oder fremden stationen in fhem integrieren. alle sonstigen system daten  daten die das api liefert können ohne probleme eingebaut werden wenn sie das noch nicht sind. die kommunikation mit dem netatmo server ist nicht blockierend.

das modul unterstützt die thermostate noch nicht da sich das bis jetzt noch niemand gewünscht hat. ich sehe aber kein problem das einzubauen.

gruß
  andre

[tuxbox]

Ok, das hört sich natürlich schon gut an. In der commandref war das für mich nicht ersichtlich.
Wobei die Thermostatsteuerung für mich selbst zumindest schon essentiell ist.

Und wie meinst Du das, dass das jetzige Modul nicht blockierend ist? Ist das nebenläufig?
Sonst blockiert ja je nach http-Antwortverhalten FHEM so lange.

Ist das Polling auch an den lastMessage stamps ausgerichtet?

Gruß,
tuxbox

[justme1968]

was fehlt denn in der commandref?

wenn du testen magst baue ich etwas für die thermostate ein.

fhem wartet nicht aktiv auf die antwort auf api Anfragen sondern verwendet select um dann Daten zu lesen wenn sie da sind.

beim pollen werden natürlich nur die daten seit dem letzten timestamp angefragt.

gruss
  andre

[tuxbox]

Es fehlt vielleicht nicht direkt, aber aufgrund der get Abfragen sah es für mich so aus.
Aber was imho z.B. fehlt ist die Syntax und Semantik zur Modul-Definition.

Beim Pollen meinte ich nicht, welche Daten angefragt werden, sondern, dass z.B.
überhaupt erst Updates auf dem Server im 5-, 10- oder 20- Minuten Rhytmus verfügbar
sind, die man durchaus aber sehr genau ermitteln und da dann das Update holen kann.
Es sei denn, man mag noch ein paar nicht dokumentierte Api-Calls zum force-sync
bei netatmo einsetzen.

Gruß,
Frank

P.S.: Aber Du hast natürlich recht. Wenn der FHEM-Kern nur blockierend liest, wenn schon Daten
da sind und Du auch die ganzen Systemattribute bereit stellst, ist die Erweiterung für die meisten
wohl eher unnütz.
Hast Du geplant, das Modul evtl. noch um die Thermen-Steuerung zu erweitern?

[justme1968]

was meinst du mit syntax und semantik?

define <name> netatmo [ACCOUNT] <username> <password> <client_id> <client_secret>
...
If a netatmo device of the account type is created all fhem devices for the netatmo devices are automaticaly created.

du legst also nur ein mal ein device für deinen account an und alles andere geht automatisch.


zum update: jetzt weiss ich was du meinst. zur zeit wird das abfrage intervall nicht dynamisch in abhängigkeit von der tatsächlichen verfügbarkeit angepasst. die readings die in fhem angelegt werden sind aber alle auf den tatsächlichen zeitpunkt des jeweiligen wertes zurückdatiert.

wenn du erfahrung damit hast den zeitpunkt auf das tatsächliche update bei netatmo zu synchronisieren kann ich das aber gerne einbauen. wenn man das ganze zur heizungssterung verwendet ist das vermutlich sinnvoll. reicht die differenz zwischen aktuellem und letzten timestamp für die voraussage des nächsten zeitpunktes? dann könnte man einfach diesen wert mit einer ober- und untergrenze versehen und das update dann ein paar sekunden danach machen.

wie gesagt gab es noch nicht den bedarf. ich sehe aber kein problem das direkt ins modul mit einzubauen und würde das gerne machen wenn es mindestens ein versuchskaninchen gibt das auch die entsprechde hardware hat.

gruss
  andre

[tuxbox]

Ja, im Prinzip reicht die Differenz. Bei mir läuft das nach vielem Austesten (der Intervall und Retrywerte) ungefähr so ab (vorsicht pseudocode artig ):
my $intervall =620; #10Minuten 20 Sek.
my $directRetry = 120; # 2 Minuten direkt nach erfolglosem Versuch
my $nxtRetry = 0;
my $isDirectRetry = 0;
my $retryOffset = 0;

...
if (time() >= $lastStamp + $intervall + $retryOffset + $isDirectRetry) {
  my $newStamp = update_na();
  if ($newStamp == $lastStamp) {
    if (!($isDirectRetry)) {
      $isDirectRetry = $directRetry;
      Trigger in +$directRetry;
    } else {
      $isDirectRetry = 0;
      my $newStamp = update_na();
      if ($newStamp == $lastStamp) {
        $retryOffset += $intervall;
      } else {
        $retryOffset = 0;
        $lastStamp = $newStamp;
      }
      Trigger in +$intervall;
    }
  } else {
    $lastStamp = $newStamp;
    $retryOffset = 0;
    $isDirectRetry = 0;
    Trigger in +$intervall;
  }
}

d.h. nach 10:20 Minuten vom letzten Zeitstempel an neu holen. Wenn keine neuen Daten, nochmal in zwei Minuten holen. Aber wenn da dann auch keine neuen Daten vorliegen, hat es keinen Sinn nochmal einen Retry zu machen, sondern stattdessen besser ein Zeitfenster weiter zu gehen, also 2*10:20 Minuten vom letzten Zeitstempel. usw.

Hab noch nicht in Deinen Code geschaut, aber machst Du einen RefreshToken? Wenn nicht (bei ständig neuem Token) kam es bei mir nach einigen Wochen zu einem AuthenticationError,
weil die neuen Token sich von der Gültigkeit her mit den vorherigen Überlappen, was aber anzahlmäßig nicht unbegrenzt erlaubt ist.
Andererseits sind die expiry Rückmeldungen bei einem Refresh hin und wieder scheinbar gewürfelt, zumindest läuft er dann ganz wesentlich früher aus als angegeben, was natürlich
abgefangen werden muss.

Wenn meine Familie nicht im Haus ist kann ich Deine Erweiterungen für die Thermostatsteuerung gerne testen. Da solltest Du aber bitte zusätzlich den undokumentierten Api-Call
syncthermstate(token,device_id) mit als set Befehl einbauen. Ohne ist der aktuelle Zustand (vorallem, ob z.B. gerade der Brenner aktiviert ist) oft sogar deutlich "älter" als eine
halbe Stunde.
Laut Anfrage bei netatmo ist der Call unschädlich und kann ruhig benutzt werden. Aber sie planen nächstes Jahr hierfür eine eigene Infrastruktur zu veröffentlichen.
D.h. das wird dann nochmal überarbeitet werden müssen.

Gruß,
Frank

P.S.: Meine Äußerung, dass das netatmo Modul rudimentär sei, war übrigens nicht beleidigend oder abwertend gemeint. Manchmal ist ja auch eine einfache Lösung
auch durchaus einer vollständigen Umsetzung vorzuziehen. Aber da habe ich mich ja sowieso sehr getäuscht. Das ist ja dann schon
nahezu perfekt.
Noch mehr offtopic: Meine netatmo Umsetzung kommt historisch auch aus einer ganz anderen Ecke und war nie als Konkurrenz zu Deinem Modul gedacht.
Ich hatte bis vor ein paar Wochen ein selbst entwickeltes Heimautomatisierungssystem im Einsatz, bei dem ich z.B. den MAX Cube, netatmo Stationen eben,
WS2300 Wetterstation, Mobile App (für Floorplan-ähnliche Sicht), Mailbenachrichtigungen, MySQL-Anbindung zum Datenlogging, plot.ly-Anbindung für
Graphen etc. etc. zusammengebracht habe.
Einige Subsysteme sind davon habe ich der Einfachheit halber jetzt auch noch im Einsatz und an FHEM angebunden. U.a. eben die netatmo-Ansteuerung....

[justme1968]

keine angst. ich hatte deine frage nicht als konkurenz oder schlecht machen verstanden. sondern nur als mangelnde information

das liegt aber sicher auch an der sehr kurzen dokumentation in der commandref. das wiki ist etwas ausführlicher.


aber zurück zum thema: die dynamische änderung des zeitrasters schaue ich mir an und baue es ein. dauert aber ein wenig.

zur zeit wird das token automatisch aktualisiert nach 3/4 der restzeit und wenn ein api call gemacht werden soll und die rest lebensdauer < 5 minuten ist. ds scheint zu funktionieren. zumindest habe ich hier noch keine negativen rückmeldungen bekommen.

ich habe übrigens selber gar keine netatmo devices (in der firma gibt es seit kurzem welche und es war praktisch das modul schon zu haben ). von daher habe ich kein problem damit wenn das modul nicht für alle anwendungsfälle passen würde und wenn du etwas hast das besser funktioniert ist das natürlich ok.

aber wenn du ideen und erfahrungen hast ist es unterm strich vermutlich produktiver die energie in ein einziges modul zu stecken als zwei zu haben.

das mit dem thermostat schaue ich mir auch auf jeden fall an. unabhängig davon das ich persönlich es als kritisch ansehen würde meine heizung mit etwas zu steuern das aufs internet angewiesen ist. wenn es aber nur zusätzlichen komfort bring ist das natürlich wieder ok.

vielleicht magst du mir mal ein paar json nachrichten die in verbindung mit dem thermostaten relevant sind schicken? dann kann ich auch selber besser testen wenn ich das einbaue.

gruss
  andre

[smartie73]

Hallo Profis,

Eigentlich wollte ich nur via Raspberry Pi mein Garagentor per iPhone steuern - mittlerweile bin ich aber auf FHEM gestossen und habe Appetit auf viel mehr bekommen (bin also blutiger Anfänger mit FHEM), insbesondere weil ich eh schon sehr viel unterstützte Geräte beisammen habe (netatmo, max! eq-3, Luxtronik WP Steuerung).

Meine Frage: Die Geräte (WP-Steuerung, netatmo, ...) "sehe" ich in FHEM alle und bekomme auch gültige Daten. Was ich nun als erstes machen möchte ist eine automatische Absenkung der Temperatur wenn niemand zu Hause ist.

Ich habe gesehen, es gibt mit FHEM mittels PRESENCE verschiedene Möglicheiten hierzu - wenn ich mir aber meine netatmo Daten anschaue habe ich den Eindruck, dass ich mit dem Sonometer in netatmo hier auch einen zuverlässigen Indikator habe...wenn das Sonometer unter 40 dB anzeigt, dann ist niemand zu Hause, die WP könnte ich dann via ReturnTemperatureSetBack zurück fahren.

Aber wie geht das nun konkret? Der Befehl set WP ReturnTemperatureSetback -2 funktioniert, nun müsste ich den aber nur in Abhängigkeit vom Sonometer ausführen (noise <40 dB) und das regelmässig checken...umgekehrt wenn noise >40 dB sollte ReturnTemperatureSetBack auf 0 gesetzt werden.

Geht das mit den existierenden Modulen bereits und kann mir wer einen Tip geben wie genau?

Beste Grüsse aus der Schweiz

smartie73

[justme1968]

schau dir notify, THRESHOLD oder DOIF an. zu allem findest du beispiele hier im forum oder im wiki. auch das einsteiger pdf sollte dir weiter helfen.

gruss
  andre

[smartie73]

Hallo,

Ist/wäre das tatsächlich so einfach:

define di_heizungsabsenkung DOIF ([netatmo_D70:ee:50:04:63:ca:noise] < 40) (set WP returntemperaturesetback -3) DOELSE (set WP returntemperaturesetback -1)

Problem sind nun aber glaub die Doppelpunkte im Devicenamen...netatmo_D70:...kann ich die : irgendwie maskieren oder kann ich dem Device irgendwie einen anderen Namen geben?

Gruss

smartie73

[justme1968]

du kannst das device (wie jedes andere auch) mir rename umbenennen.

gruss
  andre

[smartie73]

Danke, das hat geklappt - die grosse Frage ist wie kann ich das testen? Status von dem Teil ist jetzt immer "initialized"...?

Gruss

smartie73

[smartie73]

...geht! 

[miwu]

Ich grabe diesen alten Thread nur ungern wieder aus. Ich interessiere mich für das Netatmo Thermostat um meine Gasetagenheizung zu steuern. Ist es hierfür denn schon ein FHEM-Modul oder ist vielleicht schon etwas in der Pipeline?