Neue Beta Test Runde für alle MAX Module

Begonnen von Wzut, 14 Oktober 2020, 17:41:04

Vorheriges Thema - Nächstes Thema

Wzut

@scooty und diejenigen die Multi IO am cm Device nutzen und jetzt auch diese Probleme haben :
löscht bitte am cm Device das Attribut IODev , save und FHEM restart.
Zumindest in meiner Testumgebung ist dann der Wechsel wieder ohne Fehler möglich.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

scooty

Kann ich bestätigen, seit Löschung des Attributs und Restart keine Meldungen mehr.
8)

Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

Wzut

OK, danke für die Rückmeldung.
Dann bekommt 14_CUL_MAX noch ein paar Zeilen die das IODev Attribut löschen sobald der User IOgrp mit mehr als einem gültigen CUL anlegt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Nuems

Eine kurze Rückfrage zu #36:
Verstehe ich es richtig, dass die neuen Möglichkeiten zur Temperaturabfrage in 10_MAX nicht mit dem MAXCube funktionieren, sondern einen CUL erfordern?

Hintergrund:
Mein FHEM soll ohnehin gerade auf einen anderen Server umziehen und das ist eine gute Gelegenheit zum Aufräumen/Ausmisten und (gerade außerhalb der Heizperiode) ggf. auch dafür, den Cube doch mal zu flashen. Bisher fehlte ein wenig der Anreiz, die Temperaturabfrage wäre ein solcher.

Wzut

@Nuems, so ist es : 14_CUL_MAX only !
Wenn du aber jetzt ein Wechsel planst bitte denke daran und notiere dir deine aktuelle MAXID und ziehe Streßfrei vom CUBE auf CUL_MAX um ohne Werksreset !
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

neyzen

Hi,
ich nutzt jetzt schon die Beta Version seit Anfang des Jahres mit einem externen Sensor.
Mir ist aufgefallen das ich in dieser Zeit schon zwei mal die Batterien wechseln musste. Bei den anderen Thermostaten die noch mit dem Cube laufen ist der Wechsel so alle 2 Jahre. Kennt das jemand?

_fhemuser_

Hallo,

ich habe auch die 3 angepassten Dateien aus dem dem ersten Post installiert, weil mich die aktuelle Temperatur der HTs interessiert und ich mit dem Scanner nicht warm wurde.

Aber seit dem habe ich massive Probleme mit den zwei vorhandenen CULs. Einer ist mit 433 MHz für Schaltsteckdosen und einer mit 868 MHz für MAX!

Aus dem verlinkten thread https://forum.fhem.de/index.php/topic,120603.0.html verstehe ich, dass die ursprünglichen Zuordnungen USB1 für 433 MHz und USB2 für 868 MHz wohl nicht mehr funktionieren.

Da mit die Schaltung der Steckdosen wichtiger ist als die Anzeige der Raumtemperatur werde ich die 3 Module wieder durch die Originaldateien ersetzen müssen.

fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Wzut

 @_fhemuser_ , du verwechselst Äpfel mit Birnen !
Das leidige IODev Thema kommt nicht von den MAX! Modulen, da kannst du installieren an Versionen was du möchtest.
Dein Problem scheint  eher ein alt bekanntes zu sein, d.h absolute Namen (/dev/ttyUSB0) verwendet statt by-path oder by-id
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

_fhemuser_

Hallo Wzut,

bei mir wurde immer angezeigt beim CUL SOA statt ok und im Logfile: 2021.07.23 09:26:25 1: MAX_CUL_Stick, Send Queue error CUL CUL866 did not answer request for current credits. Waiting 5 seconds

Da das mit den Originalen Module nie war und in diesem thread auf Fehler mit dem USB verlinkt wurde, hatte ich den Verdacht, dass dort der Fehler liegt.

Benötigten die 3 Betamodule soviele Credits?
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

_fhemuser_

#84
Ich habe jetzt noch einmal eine Woche lang die originalen Module ohne Fehlermedung installiert gehabt.

Nachdem ich heute vormittag wieder die 3 Betamodule installierte stieg die SendCue stark an und der Status des CUL steht auf UAS.

der CUL ist eingebunden mit: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062CUL-if00-port0@38400 1234

Wo kann der Fehler liegen?

fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Wzut

Ich sehe da noch immer nicht den Zusammenhang.
Der CUL wird direkt bedient von 00_CUL.pm -> nicht meine Baustelle.
00_MAXLAN.pm brauch einen Cube mit orignal Firmeware -> hast du doch gar nicht.
14_CUL_MAX.pm nutzt Funktionen von 00_CUL, egal ob altes Modul aus dem SVN oder die Beta Version.
Aber ohne gescheites verbose 5 Log ist das halt wie immer alles reine Kaffeesatz Leserei ......
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

_fhemuser_

Den Original Cube habe ich vor Monaten in Rente geschickt, da er die Konfiguration immer wieder vergessen hatte.

Wenn die 3 Betadateien unbedingt den Cube bennötigen, schließe ich ihn wieder an und richte ihn in fhem ein und entferne den CUL.

Bei den zukünftigen Fehlern erstelle ich Logdateien und füge sie hier ein.
fhem in der aktuellsten Version auf:
Raspberry 4 mit SSD | fhem2fhem | NanoCul433 Selbstbau | NanoCul868 Selbstbau | DbLog | MAX! | zigbee2MQTT | homebridge | alexa
inkl zigbee2MQTT Server, Unifi-Server

Raspberry 4 mit SD Karte | fhem2fhem | motioneye

Wzut

Wenn du keinen Original Cube mehr im Einsatz hast macht der Austausch der 00_MAXLAN.pm doch gar keinen Sinn !
D.h. wie willst du die Funktion eines Modules testen wenn du die dazu notwendige Hardware gar nicht mehr in Betrieb hast.
Anyway, ich hoffe das nach dem Wechsel vom Cube zum CUL auch das entsprechende define aus der config gelöscht hast bzw. das komplette MAXLAN Device.

Als erstes wäre schon mal wichtig zu wissen wie du vom Cube auf den CUL umgezogen bist :
a. Soft und einfach mit Übernahme der MAXID vom MAXLAN Device zum CUL_MAX Device ?
oder
b. Hart und schwer mit neuer MAXID am CUL_MAX Device und Werksreset aller Geräte ? 

In jedem Fall wäre ersteinmal ein list deines cm Device interessant.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

benkler

ich bin nun leider wieder von der Beta auf die SVN version gegangen, da bei mir leider ein Paar Thermostate ziemlich defekte werte an Fhem übermittelt haben.
Siehe screenshot

FHEM (Docker), Homebridge (Docker), Homematic IP, nanoCUL 433 + 868 a-culfw, jeeLink Clone, Diverse IT Sensoren, ems-esp, Netatmo und noch einiges mehr

Wzut

So ein Screenshot alleine bringt leider niemand wirklich weiter. ( ich erkenne da gar nichts )
Ein entsprechendes Log hätte hilfreich sein können eventuel vorhandene Ausreisser zu erkennen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher