Die MAX Module heute und die Aussichten für 2020

Begonnen von Wzut, 22 Dezember 2019, 13:46:18

Vorheriges Thema - Nächstes Thema

Wzut

Zitat von: Parador am 01 Mai 2020, 13:31:04
Ich habe gerade mal einen Neustart gemacht und jetzt scheint der Geist verschwunden zu sein!
Das wäre jetzt auch mein erster Rat gewesen. Es gibt Fälle (die ich selbst schon hatte, aber nicht reproduzieren konnte) wo sich so ein Geist hartnäckig hält.
I.d.R. spuckt FHEM den auch nicht via list TYPE=MAX aus.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Parador

Nachdem Du ja immer ganz tolle Dinge mit einbaust, dürfte ich was auf eine Wunschliste setzen?

  • Wäre evtl. eine Zeitverzögerung über ein wait Attribut noch denkbar? Szenario: (Terrassen)tür die nur kurz geöffnet wird um rein/raus zu gehen, da muß nicht sofort auf window-open-temp heruntergefahren werden...
  • Ich bin mir noch nicht sicher, ob es von der Programmierung sinnvoll ist.. da man ja mehrere Vsc anlegen kann.
    Aber vielleicht ist es machbar, dass bei einen vSC mehrere FK aufehmenbar sind ? d.h. das es z.B. "ExternalSensor1 bis 5" gibt, und solange einer offen ist, bleibt es auf offen? Mehrere Fenster,(-Flügel) oder Fenster und Tür pro Zimmer könnte es schon öfter geben :-)



Wzut

Zitat von: Parador am 01 Mai 2020, 13:31:04
allerdings wüsste ich nicht wo ich ein Reading ändern sollte.
*seufz* , ich hatte dir das Zauberwort bereits genannt : setreading -> https://fhem.de/commandref_DE.html#setreading

Zitatsteht inzwischen die richtige 6-Stellige MaxID (020401) darin, das geht ja über die DEF.
genau hier liegt der Hund begraben, sobald man mittels DEF edit die Adresse ändert bleibt die alte Definition mit der alten Adresse als Leiche zurück.
Habe das nun nachstellen können und wird in einem späteren Update gefixt. Bis dahin ist man auf der sichern Seite wenn man das Device komplett löscht und mit der richtigen Adresse neu anlegt.

Zitat von: Parador am 01 Mai 2020, 18:59:17
Wäre evtl. eine Zeitverzögerung über ein wait Attribut noch denkbar?
nein, ich werde nicht versuchen DOIF Teile (wait) oder notify ( disabledAfterTrigger ) in den MAX Modulen nachzubauen. Wer das haben möchte muß die Module benutzen deren Job soetwas ist und den auch wesentlich besser machen als Teilclone.

Zitatdass bei einen vSC mehrere FK aufehmenbar sind
auch das macht IMHO keinen Sinn , ein vSC ist ein Ersatz für einen echten MAX FK. Wie ich schon schrieb können MAX HTs & WTs mehr als einen FK als Sensor verwalten. Warum also nicht zwei vSC ? Für Gruppenabfragen oder Schaltungen würde ich mir mal eines der darauf spezialisierten FHEM Module anschauen, bzw ganz neu : 98_combine -> https://forum.fhem.de/index.php/topic,110165.0.html 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

willyk

Zitat von: Parador am 01 Mai 2020, 18:59:17
Wäre evtl. eine Zeitverzögerung über ein wait Attribut noch denkbar? Szenario: (Terrassen)tür die nur kurz geöffnet wird um rein/raus zu gehen, da muß nicht sofort auf window-open-temp heruntergefahren werden...[/li][/list]
Dafür gibt es schon einige Lösungen:
https://forum.fhem.de/index.php/topic,49635.msg413616.html#msg413616
https://forum.fhem.de/index.php/topic,49852.msg416026.html#msg416026
Gruss
Willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Parador

ZitatDafür gibt es schon einige Lösungen:
https://forum.fhem.de/index.php/topic,49635.msg413616.html#msg413616
https://forum.fhem.de/index.php/topic,49852.msg416026.html#msg416026
so ähnlich habe ich es aktuell mit den alten FSC und Doifs gelöst (vielleicht noch nicht so perfekt wie in den Beispielen, danke willyk), hatte nur Potential gesehen sich zusätzliche Doifs sparen zukönnen... muss aber ja nicht sein... ;-)

Zitat*seufz* , ich hatte dir das Zauberwort bereits genannt : setreading -> https://fhem.de/commandref_DE.html#setreading
Ja, ich kenne "setreading" nur waren wir uns ja schon einig, dass nirgends ein Reading mit dem Wert auftauchte... also nicht wie, sondern wo war das Problem ;-))
Ist ja aber erledigt...
Danke nochmal für die Hilfestellungen!

smoki3

Ich habe mich versucht meine alten fake WTs mit der neuen Methode zu ersetzen. Ich benutze Xiaomi Zigbee Temperatur Sensoren.

Ich habe bei meine HT nun external Sensor "BZ_TEMP:temperature:1" definiert, damit mit jeden update die Temperatur zum Thermostat gesendet wird.

Leider stürzt fhem komplett ab sobald der Temperatursensor Daten schickt. Ohne "BZ_TEMP:temperature:1" funktioniert alles.

Wzut

Ein Stück Logfile vom Absturz wäre schön, so kann ich nur raten.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

smoki3

Um 18:22:58 hab ich den knopf am Thermometer für manuelles senden gedrückt, dann steigt fhem direkt aus.

2020.05.14 18:22:58 5: deCONZ: websocket data: $VAR1 = {
          'uniqueid' => '00:15:8d:00:03:5c:06:d8-01-0402',
          't' => 'event',
          'r' => 'sensors',
          'e' => 'changed',
          'config' => {
                        'offset' => 0,
                        'battery' => 95,
                        'on' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
                        'reachable' => $VAR1->{'config'}{'on'}
                      },
          'id' => '9'
        };

2020.05.14 18:22:58 4: parse status message for WZ_Temp
2020.05.14 18:22:58 4: WZ_Temp: lastupdated: , hash->{lastupdated}:  2020-05-14 16:14:27, lastupdated_local: , offsetUTC: 0
2020.05.14 18:22:58 5: deCONZ: websocket data: $VAR1 = {
          'id' => '9',
          'e' => 'changed',
          'state' => {
                       'temperature' => 2406,
                       'lastupdated' => '2020-05-14T16:22:58'
                     },
          'r' => 'sensors',
          't' => 'event',
          'uniqueid' => '00:15:8d:00:03:5c:06:d8-01-0402'
        };

2020.05.14 18:22:58 4: parse status message for WZ_Temp
2020.05.14 18:22:58 4: WZ_Temp: use offsetUTC 7200 from bridge
2020.05.14 18:22:58 4: WZ_Temp: lastupdated: 2020-05-14 16:22:58, hash->{lastupdated}:  2020-05-14 16:14:27, lastupdated_local: 2020-05-14 18:22:58, offsetUTC: 7200
2020.05.14 18:22:58 5: Starting notify loop for WZ_Temp, 1 event(s), first is temperature: 24.06
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> ###              start of new Logcycle                       ###
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> number of events received: 1 for device: WZ_Temp
2020.05.14 18:22:58 4: DbLog DBLogging -> check Device: WZ_Temp , Event: temperature: 24.06
2020.05.14 18:22:58 5: DbLog DBLogging -> parsed Event: WZ_Temp , Event: temperature: 24.06
2020.05.14 18:22:58 5: DbLog DBLogging -> DbLogInclude of "WZ_Temp": temperature
2020.05.14 18:22:58 4: DbLog DBLogging -> added event - Timestamp: 2020-05-14 18:22:58, Device: WZ_Temp, Type: HUEDEVICE, Event: temperature: 24.06, Reading: temperature, Value: 24.06, Unit: °C
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> ###         New database processing cycle - synchronous      ###
2020.05.14 18:22:58 4: DbLog DBLogging -> ################################################################
2020.05.14 18:22:58 4: DbLog DBLogging -> DbLogType is: Current/History
2020.05.14 18:22:58 4: DbLog DBLogging -> AutoCommit mode: ON, Transaction mode: ON
2020.05.14 18:22:58 4: DbLog DBLogging -> Insert mode: Array
2020.05.14 18:22:58 4: DbLog DBLogging -> Primary Key used in history: none
2020.05.14 18:22:58 4: DbLog DBLogging -> Primary Key used in current: none
2020.05.14 18:22:58 4: DbLog DBLogging -> processing event Timestamp: 2020-05-14 18:22:58, Device: WZ_Temp, Type: HUEDEVICE, Event: temperature: 24.06, Reading: temperature, Value: 24.06, Unit: °C
2020.05.14 18:22:58 4: DbLog DBLogging -> 1 of 1 events inserted into table history
2020.05.14 18:22:59 4: DbLog DBLogging -> insert table history committed by autocommit
2020.05.14 18:22:59 4: DbLog DBLogging -> 1 of 1 events updated in table current
2020.05.14 18:22:59 4: DbLog DBLogging -> insert / update table current committed by autocommit
2020.05.14 18:22:59 5: MAX_1262e3, NOTIFY EVENT -> Dev : WZ_Temp | Event : temperature: 24.06
2020.05.14 18:22:59 5: MAX_1262e3, updating externalTemp with 24.06
Undefined subroutine &main::validTemperature called at ./FHEM/14_CUL_MAX.pm line 490.
2020.05.14 18:23:07 5: Initializing Type Library:
2020.05.14 18:23:10 5: Cmd: >attr global userattr DbLogExclude DbLogInclude DbLogValueFn:textField-long assistantName:textField cmdIcon devStateIcon devStateIcon:textField-long devStateStyle gassistantName:textField genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock,aircondition,airpurifier,camera,coffeemaker,dishwasher,dryer,fan,kettle,oven,refrigerator,scene,sprinkler,vacuum,washer,airfreshener,fireplace,heater,blinds,awning,boiler,curtain,door,gate,hood,microwave,pregola,securitysystem,shutter,shower,valve,waterheater,ac_unit,bathtub,bed,blender,closet,coffee_maker,cooktop,dehumidifier,dehydrator,drawer,faucet,fryer,grill,humidifier,mop,mower,multicooker,pergola,petfeeder,pressurecooker,radiator,sousvide,standmixer,yogurtmaker,charger,sensor,carbon_monoxide_detector,remotecontrol,settop,smoke_detector,tv,waterpurifier,watersoftener,network,router homebridgeMapping:textField-long icon realRoom:textField sortby webCmd webCmdLabel:textField-long widgetOverride<
2020.05.14 18:23:10 5: Cmd: >attr global DbLogExclude .*<
2020.05.14 18:23:10 5: Cmd: >attr global autoload_undefined_devices 1<
2020.05.14 18:23:10 5: Cmd: >attr global latitude 48.705587<
2020.05.14 18:23:10 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2020.05.14 18:23:10 5: Cmd: >attr global longitude 10.161534<
2020.05.14 18:23:10 5: Cmd: >attr global modpath .<
2020.05.14 18:23:10 5: Loading ./FHEM/99_MyUtils.pm
2020.05.14 18:23:10 1: PERL WARNING: Subroutine myUtils_Initialize redefined at ./FHEM/99_MyUtils.pm line 15.
2020.05.14 18:23:10 1: PERL WARNING: Subroutine checkFritzMACpresent redefined at ./FHEM/99_MyUtils.pm line 21.
2020.05.14 18:23:10 5: Cmd: >attr global motd none<
2020.05.14 18:23:10 5: Cmd: >attr global room 99_System<
2020.05.14 18:23:10 5: Cmd: >attr global stacktrace 1<
2020.05.14 18:23:10 5: Cmd: >attr global statefile ./log/fhem.save<
2020.05.14 18:23:10 5: Cmd: >attr global verbose 5<
2020.05.14 18:23:10 5: Cmd: >define WEB FHEMWEB 8083 global<
2020.05.14 18:23:10 5: Loading ./FHEM/01_FHEMWEB.pm
2020.05.14 18:23:11 4: configDB reading file: ./FHEM/FhemUtils/uniqueID
2020.05.14 18:23:11 3: WEB: port 8083 opened
2020.05.14 18:23:11 5: Cmd: >setuuid WEB 5c713551-f33f-ccaa-7af7-e82ebd99127cb37d<
2020.05.14 18:23:11 5: Cmd: >attr WEB defaultRoom dash<
2020.05.14 18:23:11 5: Cmd: >attr WEB endPlotNow 1<
2020.05.14 18:23:11 5: Cmd: >attr WEB hiddenroom Everything<
2020.05.14 18:23:11 5: Cmd: >attr WEB room 99_System<
2020.05.14 18:23:11 5: Cmd: >attr WEB roomIcons 06_Hausgang:light_stairs 05_Schlafzimmer:hue_room_bedroom 04_Flur:scene_hall 60_Plots:time_graph  01_Wohnzimmer:scene_livingroom 00_Draußen:scene_summerhouse 02_Küche:scene_baking_oven 03_Bad:scene_bathroom 04_Schlafzimmer:scene_sleeping 80_Automation:rc_SHUFFLE 96_PLOTS:time_graph 99_System:edit_settings 97_LOG:time_note 98_Geräte:mqtt_device 85_Bewohner:user_unknown GoogleAssistant:alexa2 97_Battery:measure_battery_100<
2020.05.14 18:23:11 5: Cmd: >attr WEB styleData {
"f18": {
  "Pinned.menu": true,
  "hidePin": false,
  "cols.bg": "F8F8F8",
  "cols.fg": "465666",
  "cols.link": "4C9ED9",
  "cols.evenrow": "E8E8E8",
  "cols.oddrow": "F0F0F0",
  "cols.header": "DDDDDD",
  "cols.menu": "EEEEEE",
  "cols.sel": "CAC8CF",
  "cols.inpBack": "FFFFFF",
  "savePinChanges": true,
  "rightMenu": false,
  "wrapcolumns": false,
  "fixedInput": false,
  "Pinned.Room.80%5fAutomation.grp.MAX!": true,
  "Pinned.Room.GoogleAssistant.grp.Multimedia": true,
  "Pinned.Room.02%5fK%c3%bcche.grp.Fenster": true
}
}<
2020.05.14 18:23:11 5: Cmd: >attr WEB stylesheetPrefix f18<
2020.05.14 18:23:11 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2020.05.14 18:23:11 5: Loading ./FHEM/92_FileLog.pm


Vielleicht das hier?

Undefined subroutine &main::validTemperature called at ./FHEM/14_CUL_MAX.pm line 490.

Wzut

na also geht doch :) Fix habe ich eben hochgeladen ( siehe anderer Thread )
Und BTW : wir müssen ein Thema nicht in zwei verschiednen Threads behandeln, da blicke ich am Ende selbst nicht mehr durch wo ich was geschrieben habe.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

ebi4560

Hallo
Eine vielleicht ganz dumme Frage aber eine Frage welche ich nicht beantworten kann da ich hierzu keine Antwort gefunden habe. Ich verwende für meine MAX Geräte den MAX Cube im Original, eingebunden als MAXLAN. Auf Grund der Wohnungsgröße ist das ein oder andere Gerät eher schlecht in der Verbindung (RSSI bei 65 bis 75). Ein versetzen des MAX Cube ist eher problematisch da ich in einer Mietwohnung wohne. Nun zu meiner Frage : Besteht die Möglichkeit einen zweiten MAX Cube in FHEM einzubinden mit MAXLAN und zu betreiben. Den zweiten MAX Cube könnte ich per DLAN an FHEM anbinden und in der Wohnung an einer anderen Stelle platzieren.
Wie ich gelesen habe funktioniert das mit zwei CUL jetzt ohne Probleme. Für eine Antwort wäre ich dankbar.
Gruß an alle.
FHEM Server auf RPI3B, MAX! LanCube, MAX! Wandthermostate, Heizungsregler, Fensterkontakte, mySensors Temperatursensoren, Bewegungsmelder, ESP-01 Relais, KODI Server auf RPI3B, Synology NAS 218+

smoki3

Zitat von: Wzut am 14 Mai 2020, 19:24:44
na also geht doch :) Fix habe ich eben hochgeladen ( siehe anderer Thread )
Und BTW : wir müssen ein Thema nicht in zwei verschiednen Threads behandeln, da blicke ich am Ende selbst nicht mehr durch wo ich was geschrieben habe.

Fix hat funktioniert.

Eine kurze Frage noch zu dem neuen fakeWT: Muss ich trotzdem ein associate mit fakeWT durchführen? Und wie ist das verhalten wenn 30 min kein neues Event vom Thermometer kommt? Seither sind die Thermostate dann auf rferror gesprungen.

Wzut

was bitte ist das "neue" fakeWT ? Ich habe intern eine Baustelle die nennt sich virtualThermostat (ähnlich dem neuen virtualSC),
allerdings würde ich heute keinem User empfehlen damit an den Start zu gehen. D.h. wer die Funktion fakeWT brauch muß auch fakeWT benutzen.
Das ein HT "meckert" wenn es eine Zeit X keine Telegramme vom Chef WT bekommt (egal ob echt oder fake) liegt in der Firmware der HTs und darauf habe ich keinen Einfluß. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

smoki3

Mit der neuen Methode meine ich den Sensor über Externalsensor zu koppeln

Mit ist nicht klar ob ich dann trotzdem noch ein associate mit fakeWT machen muss?

Das heißt der mit dem Attribut "externalsensor" wird nicht automatisch ein neue Befehl bevor der HT auf Störung geht?

Wzut

Natürlich brauchst du das associate des HT mit dem fakeWT, da hat sich nichts geändert !
Habe ich das in der Doku so unverständlich geschrieben ?
Zitatund ausserdem über das CULMAX Device der Befehl fakeWT abgesetzt werden soll. D.h. man spart sich das im Wiki beschriebene notify und den Code Teil in der 99_myUtils
spart : notify und 99_myUtils , spart nicht : associate
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

SibbeH

Hallo Wzut
Ich bin sehr froh mit Ihrer Wartung der MAX!-Module ! !

Habe gesternabend ein algemeine Update von FHEM gemacht. Dann habe ich die Batterien eines HT gewechselt. Ich kann nicht mehr überprüfen, ob die Fehlermeldung, die in MAX_CV_Voorkamer_VR nach dem Update oder nach dem Batteriewechsel aufgetreten ist. Soweit ich weiß, ist alles in Ordnung, aber ich gehe davon aus, dass Sie an der Fehlermeldung interessiert sind (siehe Reading: error)
Internals:
   DEF        HeatingThermostat 0f893b
   FUUID      5c51ecea-f33f-5a50-d8a7-1a250eb83ded379b
   IODev      cm
   LASTInputDev cm
   MSGCNT     17
   NAME       MAX_CV_Woonkamer_VR
   NR         232
   NTFY_ORDER 50-MAX_CV_Woonkamer_VR
   STATE      20.5&deg;C
   SVN        21928
   TYPE       MAX
   TimeSlot   4
   addr       0f893b
   cm_MSGCNT  17
   cm_TIME    2020-05-15 18:25:02
   devtype    1
   type       HeatingThermostat
   READINGS:
     2020-05-14 21:41:18   PairedTo        123456
     2020-05-15 18:25:02   RSSI            -62.5
     2020-05-14 21:41:18   SerialNr        LEQ1004593
     2015-11-06 21:11:18   TimeInformationHour 4
     2020-05-15 18:25:02   battery         ok
     2020-05-15 18:25:02   batteryState    ok
     2015-11-06 21:57:33   boostDuration   5
     2015-11-06 21:57:33   boostValveposition 80
     2015-11-06 21:57:33   decalcification Sat 12:00
     2020-05-15 18:25:02   desiredTemperature 20.5
     2020-05-15 15:32:33   deviation       0.1
     2020-05-14 21:41:20   error           Invalid command/argument  81190028
     2020-05-14 21:41:18   firmware        1.0
     2020-05-15 18:25:02   gateway         1
     2020-05-14 21:51:52   groupid         1
     2020-05-15 18:24:54   lastTimeSync    2020-05-15 18:24:54
     2020-05-14 21:57:01   lastcmd         set_associate MAX_WT_Woonkamer
     2015-11-06 21:57:33   maxValveSetting 100
     2020-05-15 18:25:02   mode            auto
     2020-05-15 18:24:54   msgcnt          31
     2020-05-15 18:25:02   panel           unlocked
     2020-05-15 15:32:33   peerIDs         000000
     2020-05-15 15:32:33   peerList        Broadcast
     2020-05-15 18:25:02   rferror         0
     2020-05-15 18:25:02   state           20.5&deg;C
     2020-05-15 15:32:33   temperature     20.6
     2020-05-14 21:41:18   testresult      161
     2015-11-06 21:57:33   valveOffset     0
     2020-05-15 18:25:02   valveposition   0
   helper:
     io:
       CUL1:
         raw        Z0E1F02020F893B1234560001180029
         rssi       -62.5
         time       1589559902.42552
Attributes:
   IODev      cm
   model      HeatingThermostat
   room       Woonkamer


Um die RSSIs der verschiedenen Geräte zu überprüfen, habe ich in Fhem eine Tabelle namens RSSI. Nach der Aktualisierung wird das Datum und die Uhrzeit des Empfangs angezeigt, aber die RSSI-Werte gehen jedoch verloren. Ich mache das mit

define rssi readingsGroup .*:+.*RSSI,+.*_TIME

CUL1, cm und MAX..... gehören zu MAX!
Die anderen Geräte gehören zu FS20.

Wie sehe ich die RSSI-Werte wieder?

Mit freundlichen Grüßen
Sibbe
Raspberry Pi, CULV3, 3xCUNO, MAX Thermostat, MAX Wandthermostat, HM, HmIP. UWZ, WeekProfile