Neues Modul: 98_SmarterCoffee.pm (Wi-Fi Kaffee Maschine)

[CoolTux]

Mir ist noch etwas aufgefallen.

Wenn laut cups_max noch 3 Tassen möglich sind und ich über das Modul mir 5 machen möchte so meckert er nicht rum sondern legt brav los.
Hier wäre eine Idee die Zubereitung aus zu setzen und Status maintenance zu setzen.

[jkellerer]

Hi CoolTux,

Erstmal Vielen Dank für die Hinweise!

1. Zu Maintenance nach dem Brühen: Am Ende des Brühvorgangs setzt die Maschine spezifische Status-Bits solange die Heizplatte noch in Betrieb ist. Das ist im Modul der Status "done" und ich denke das passt auch so. 
Wenn die Heizplatte aus ist wird derzeit entweder "maintenance" oder "ready" gesetzt je nachdem welche Bedingungen erfüllt sind.
Natürlich macht es eigentlich keinen Sinn "ready" anzuzeigen wenn der Filter nicht gewechselt wurde. Es gibt nur meines Wissens keine Möglichkeit dies gut zu erkennen.
Hatte auch schon überlegt eine Art Schutz zu integrieren dass direkt nach dem Brühen kein neues Brühen möglich ist.
Status auf "maintenance" würde genau dies bewirken, mir ist aber bisher keine allgemein gültige Logik eingefallen die nicht nervt und unnötig einschränkt.
Muss in dieser Hinsicht etwas angepasst werden (z.B. "state" Reading vom Benutzer setzen lassen) damit man sich selbst helfen kann wenn man diese Funktion möchte?

2. Zu "STATE" und reading "state":
Danke für den Hinweis, das muss ich mir genauer ansehen.
Derzeit aktualisiere ich das "state" Reading immer und "$hash->{STATE}" nur fürs Verbindungsmanagement (also für DevIo) wobei "$hash->{STATE}" auch von FHEM gesetzt wird.
Wenn ich dich richtig verstehe sollte der Benutzer das "state" reading selbst setzen dürfen weshalb das Modul "$hash->{STATE}" immer setzt und das Reading nur wenn es vor der Änderung gleich "$hash->{STATE}" ist, richtig?
Hast du evtl. einen Forums oder Wiki Link für mich?

3. Die Status-Anzeige für "keine Verbindung" (z.B. weil ausgesteckt) sehe ich mir an.
Das hatte ich bisher nie ausprobiert, nur ob die Verbindung neu aufgebaut wird wenn man sie zuvor unterbrochen hat.
Was ist hier vernünftig, auf DevIO warten bis "disconnected" im "{STATE}" erscheint, selbst die Update-Rate überwachen und beim Ausbleiben der Updates den Status entsprechend anpassen, oder gibt es eine bessere Strategie?

> @mi.ke: State "opened" kommt von DevIO einem Standardmodul von FHEM das für die Verbindung zur Kaffeemaschine verwendet wird.
Ich vermute es gab bei Dir einen Verbindungsabbruch mit anschließender Wiederherstellung.
"opened" ist ein "Initialer" Status der eigentlich auf "connected" springen sollte wenn er behandelt wurde.
Da er offensichtlich nicht behandelt wird kann ich sehen was nicht richtig funktioniert hat.

4. "cups_max" wird in der Standardeinstellung ignoriert und es wird der Kaffeemaschine überlassen wie sie die Tassenmenge reduziert damit es passt.
Um dies zu ändern kann das Attribut "ignore-max-cups" auf "0" gesetzt werden (Standard ist "1") dadurch ist der Status dann "maintenance".
Hatte darüber nachgedacht den Standardwert hier auf "0" zu setzen habs aber verworfen weil die Maschine eine eigene Behandlung für den Fall hat.

Gruß, Jürgen

[mi.ke]

Sagt mal, ist das bei Euch auch so?


Wenn ich auf 10 Tassen stelle, kommen nur 8 raus,auf 12 Tassen macht die Maschine nur 10.

[jkellerer]

Das ist "normal"

[mi.ke]

Das verstehen dann wohl nur die Engländer......


Allerdings ist der Betrieb mit vorgemahlen Kaffee dann ehr GlückSache.


Das ist fast ein Grund das Ding wieder zurückzuschicken.

[CoolTux]

2. Zu "STATE" und reading "state":
Danke für den Hinweis, das muss ich mir genauer ansehen.
Derzeit aktualisiere ich das "state" Reading immer und "$hash->{STATE}" nur fürs Verbindungsmanagement (also für DevIo) wobei "$hash->{STATE}" auch von FHEM gesetzt wird.
Wenn ich dich richtig verstehe sollte der Benutzer das "state" reading selbst setzen dürfen weshalb das Modul "$hash->{STATE}" immer setzt und das Reading nur wenn es vor der Änderung gleich "$hash->{STATE}" ist, richtig?
Hast du evtl. einen Forums oder Wiki Link für mich?

3. Die Status-Anzeige für "keine Verbindung" (z.B. weil ausgesteckt) sehe ich mir an.
Das hatte ich bisher nie ausprobiert, nur ob die Verbindung neu aufgebaut wird wenn man sie zuvor unterbrochen hat.
Was ist hier vernünftig, auf DevIO warten bis "disconnected" im "{STATE}" erscheint, selbst die Update-Rate überwachen und beim Ausbleiben der Updates den Status entsprechend anpassen, oder gibt es eine bessere Strategie?

Hallo Jürgen,

Vielen Dank für Deine Erklärungen. Deine Antworten haben viele meiner Fragen erschlagen 
Bleiben die beiden Fragen im oberen Zitat übrig.

2. STATE und state
Es wird seit einiger Zeit empfohlen nur noch das Reading state vom Modul ändern zu lassen, da das Internal STATE sich dem Reading state orientiert, es sei denn der User wünscht eine andere Anzeige des Internals STATE. Wo das nun genau steht vermag ich nicht zu sagen. Sind Informationen die man im laufe eines Forumslebens im Entwicklerforum so auf schnappt.

3. Leider kenne ich mich mit DevIO nicht aus, ich verwalte meine Socketverbindungen selber im Modul. Da habe ich festgestellt das ein radikales beenden der Verbindung durch ziehen des Netzwerksteckers oder ausschalten über Power vom Socket nicht bemerkt wird. Ich wurde hier versuchen alle X Sekunden einfach ein Update zu machen.
Schön wäre auch wenn der User selber die Möglichkeit hätte ein set statusRequest machen zu können wo alle Readings aktuell befüllt werden.



Grüße
Leon

[krikan]

2. STATE und state

https://wiki.fhem.de/wiki/DevelopmentState

[CoolTux]

Vielen Dank. Das hat uns gefehlt.


Grüße

[mi.ke]

Wenn ich auf 10 Tassen stelle, kommen nur 8 raus,auf 12 Tassen macht die Maschine nur 10.

Das ist "normal"

Also entweder hab ich eine Montagsmaschine erwischt oder ich bin nicht in der Lage mit dem Ding um zugehen.

- Modul zeigt an 3 Tassen möglich
- APP also zeigt "Wasser leer"
- Direkt an der Maschine eingestellt "2 Tassen" ergibt "no Water"
- Direkt an der Maschine eingestellt "1 Tassen" ergibt "no Water"
Sind aber tatsächlich noch für 2 Tassen Wasser in der Maschine ( Wasserstandsanzeige, die man aber beim einfüllen nicht sieht)
Wenn man für 12 Tassen reinfüllt, läuft der Mist über (WAF war gleich NULL)
Da die neue aber nur 10 ausspuckt wenn man 12 drückt......

Die alten Kaffeemaschinen hingen schon an einer Zeitschaltuhr, da gabs ab 1:00 Uhr nur noch schwarz-weiss-Flimmern im Fernsehn, und der Kaffee war trotzdem morgens rechtzeitig fertig.

Das bekomm ich meiner Frau nie schöngeredet 

[jkellerer]

Hi Leon,

Danke Dir! D.h. ich schau mir an ob ich komplett auf das setzen von "STATE" verzichten kann.
Bzw. werd mir erstmal die Forumsdiskussion ansehen. @krikan: Vielen Dank für den Link.

Zu DevIO, hab gestern sehr lange gewartet und irgendwann war der Status "disconnected" und entsprechend das DevStateIcon nicht mehr grün.
Nach dem wieder einstecken war es sofort wieder grün, d.h. ein reconnect funktioniert sofort.
D.h. im Prinzip funktioniert es über DevIO nur die Reaktionszeit bei einem Verbindungsabbruch ist ewig. Ich denke auch ich werde einfach einen Zwischenstatus einbauen wenn keine Updates mehr von der Kaffeemaschine kommen das sollte kein Problem sein, denn wenn die Verbindung da ist werden die alle paar Sekunden gesendet oder sofort bei einem Ereignis.

Außerdem überlege ich mal noch wie man evtl. von außen "maintenance" erzwingen kann, damit man sich besser selbst helfen kann.
Das mit "get state" überleg ich mir auch noch.

Danke nochmals für das Feedback!

Grüße, Jürgen

[justme1968]

module sollen nur das reading state (und natürlich andere readings) verwenden.

fhem schreibt das state reading automatisch nach STATE. STATE ist das was im frontend angezeigt und für icon verwendet wird.

wie genau STATE aus state (oder anderen readings) abgeleitet wird kann der anwender über stateFormat beeinflussen.

[jkellerer]

Hi justme1968,

Danke Dir. Genau das mache ich auch fast weil mir aufgefallen war das FHEM es automatisch ins Internal setzt.
Für DevIO hatte ich gelegentlich auch {STATE} gesetzt ich muss aber erst nochmal nachsehen warum ich das genau getan hab um zu entscheiden ob ich es auch lassen kann.

Gruß, Jürgen

[jkellerer]

Hi mi.ke,

Es klingt fast so als wäre bei dir die Verbindung zur Kaffeemaschine nicht stabil oder das Modul hat in deiner Konfiguration einen Bug der bisher noch unentdeckt ist (wg. "opened" Status der nicht verschwindet und einer inkorrekten Anzeige der Tassenmenge).
Hier benötige ich noch ein wenig mehr Informationen (z.B. Log mit ATTR {name} verbose 5) von dir um zu helfen. Hatte gestern einen Verbindungsabbruch provoziert konnte aber das Problem dass "opened" nicht behandelt wird nicht reproduzieren. Auch die manuelle Bedienung an der Maschine erzeugt bei mir keine Probleme.

Generell muss ich sagen wenn für dich ein Timer an einer Standardmaschine funktioniert (also du keinen frisch gemahlenen Kaffee haben musst) dann ist diese Maschine nicht unbedingt das richtige. Über die kleineren Macken die das Ding hat (z.B. zu kleiner Tank) muss man hinwegsehen können und das geht nur wenn man trotzdem einen Mehrwert sieht.

Gruß, Jürgen

[CoolTux]

Hallo Jürgen,

Ich hatte heute im laufe des Vormittags folgende Meldung im Log

Code Auswählen Erweitern


2017.05.03 08:49:19 3: Command :: Failed [carafe_required_status]; Cause: Invalid command
2017.05.03 08:49:19 3: Command :: Failed [cups_single_mode_status]; Cause: Invalid command
2017.05.03 08:49:19 1: 10.6.34.46:2081 reappeared (SmarterKaffeeKu)
2017.05.03 08:49:20 3: notifySmarterCoffeeKu return value: HASH(0x1e6cc30)
2017.05.03 08:49:20 3: Command :: Failed [cups_single_mode_status]; Cause: Invalid command
2017.05.03 08:49:20 3: Command :: Failed [cups_single_mode_status]; Cause: Invalid command


Zu diesem Zeitpunkt wurde der Maschine Strom zugeführt. Ich gehe also davon aus das DevIO hier eine Verbindung aufgenommen hat und das Modul sich die neusten Daten vom Device besorgt hat.


Grüße

[CoolTux]

Meine Maschine steckt seit Stunden im Status opened

Code Auswählen Erweitern


Internals:
   CFGFN
   CONNECTION STATUS: 3207120001027e (00000111) | COMMAND: 4f7e => 03697e
   DEF        10.6.34.46
   DeviceName 10.6.34.46:2081
   FD         10
   FIRMWARE   15
   INVALID_DEVICE 1
   NAME       SmarterKaffeeKu
   NOTIFYDEV  global,SmarterKaffeeKu
   NR         533
   NTFY_ORDER 50-SmarterKaffeeKu
   PARTIAL
   PENDING_COMMAND 647e
   STATE      invalid
   TYPE       SmarterCoffee
   Helper:
     Dblog:
       State:
         Logdbcurrent:
           TIME       1493820469.78998
           VALUE      off
   Readings:
     2017-05-03 11:11:55   carafe          present
     2017-05-03 11:11:55   cups            2
     2017-05-03 11:11:55   cups_max        6
     2017-05-03 11:11:55   grinder         enabled
     2017-05-03 11:11:55   hotplate        off
     2017-05-02 16:08:53   hotplate_on_for_minutes 15
     2017-05-03 13:33:10   last_command    cups_single_mode_status
     2017-05-03 13:33:10   last_command_message Invalid command
     2017-05-03 13:33:10   last_command_success no
     2017-05-03 15:49:01   state           opened
     2017-05-03 11:11:55   strength        medium
     2017-05-03 11:11:55   strength_level  2
     2017-05-03 11:11:55   water           half
     2017-05-03 11:11:55   water_level     50
Attributes:
   alias      Coffee Machine
   default-hotplate-on-for-minutes 15 5=20 8=30 10=35
   devStateIcon { SmarterCoffee_GetDevStateIcon($name) }
   event-on-change-reading .*
   event-on-update-reading last_command.*
   group      Kaffeemaschine
   room       Küche
   sortby     1
   strength-extra-percent 1.4
   webCmd     strength:cups:start:hotplate:off


Leider hilft auch kein get Befehl für Verbesserung.