Wenn ich mit aktueller Beta (aber auch mit älterer beta) versuche, ein 2. CUL_MAX anzulegen, so bekomme ich immer
"a CUL_MAX device with address 122456 is already defined !"
Alternativ reicht auch schon ein Klick auf def und dann modify für die FM.
Ich habe es mal auf einer fhem Instanz ohne beta getestet, da geht es problemlos.
Ich habe in der Beta drin das es wie früher (https://forum.fhem.de/index.php/topic,41839.msg348776.html#msg348776 ) nur ein CUL_MAX Device pro FHEM Instanz geben darf, anders ist das Thema mehrere IOs unter einen Hut zu bringen meiner Meinung nicht vernünftig umsetzbar.
Aber wozu benötigst du das zweite CUL_MAX Device ? Ich bin der Meinung mit den neuen Attributen jedes Sezenario abdecken zu können.
Ah okay, war spät gestern ;D
Aber dann kann man aktuell die CUL_MAX Id nur ändern, indem man das device löscht und neu anlegt...
Ob das jetzt ein häufiges Szenario ist, steht auf einem anderen Papier.
Dann teste ich jetzt mal die Beta voll aus mit mehreren CUNs.
Gruß
Maui
Die ID verliert eh ihre Bedeutung sobald die IOgrp ins Spiel kommt. Langfristig soll sie eh ganz am CUL_MAX Device verschwinden und nur noch die maxid des CUL genutzt werden.
Dh. aber, wenn ich jetzt aktuell noch 2 Wolken habe mit 2 IDs, dann muss ich die mit der falschen Wolke trotzdem erstmal resetten, damit sie dem richtigen CUL_MAX zugeordnet werden?
Am Ende passiert die Zuordnung dann aber nicht mehr über die ID, sondern über den CUL_MAX?
nein, nein
a. am Cul_MAX irgend eine ID eintragen (ausser 111111 und 222222) und das Attribut IOgrp mit allen verwendeten CULs setzen
b. an jedem CUL das Attribut maxid auf die ID setzen für die er zuständig sein soll beim senden.
c. an jedem MAX Device das Attribut CULdev auf den CUL setzen der für dieses Gerät das senden übernehmen soll und der muss natürlich die maxid haben die das MAX Device als Zentrale kennt.
d. FHEM neu starten
e. nach 30 Sekunden die CULs checken , deren InitString muß jetzt die maxid enthalten
edit : ich würde langfristig keine zwei IDs verwenden, das beschneidet nur deine Möglichkeiten. Um so wenig Arbeit wie möglich zu haben würde ich der ID mit den meisten Geräten den Vorzug geben und die anderen resetten und neu anlernen (natürlich ohne sie in FHEM zuvor zu löschen ! )
Danke für deine Geduld ::)
Ich denke langsam habe ich es verstanden.
ok, aber da fällt mir noch etwas ein wenn du jetzt mehr als einen CUL einsetzen möchtest :
( wundere mich das da bisher niemand gefragt hat ) Du wirst im MAX Device dann zusätzliche Readings haben die dir den jeweiligen RSSI Wert zum CUL anzeigen , bsp
2020-01-30 08:45:18 CUL2_RSSI -130.5
2020-01-30 08:45:18 CUL_RSSI -45.5
nicht wundern über den extrem schlechten Wert des CUL2 :) , dieser hat intern einen Offset von -50 bekommen um ihn zusammen mit CUL direkt in einem Plot anzeigen zu können ohne dort eine Formel definieren zu müssen ( werde ich dann auch mal raus nehmen da es für meine Faulheit war)
Hmm bisher habe ich noch nicht solche Readings. Habe nur zB
RSSI -73.5
Bei den nach Reset neu angelernten habe ich
PairedTo 000000
Ist das so richtig?
Das CULdev setze ich zwar bei allen MAX Devices, aber bei FKs und Eco Tastern ist es nicht so wichtig, oder?
Da ist fhem ja eher Empfänger.
hmm , PairedTo 000000 ist Broadcast und kein echtes Pairing , das sollte unter peers erscheinen.
Was war es denn für ein Device ? Vllt ein FK ? dann ist sowieso Vorsicht geboten !
Um an die "echten" direkten CUL RSSI Werte zu kommen musst du bei jedem MAX Device das Attribut debug auf 1 setzen, kannst du auch beim CUL_MAX Device machen, denn so sieht man einfach mehr gerade in der Testphase.
Auch bei Tastern und FKs ist das CULdev wichtig !
Im Normalbetrieb senden die zwar nur, aber sobald da eine neue Batterie eingelegt wird wollen sie ihren Pair-Pong (Re-Pairing meldung im Log) von ihrer Zentrale haben und nicht von irgend wem :)
Jetzt weiß ich was du mit dem -50 meinst. ::)
Ne, ist ein HT bzw. alle von "oben" vom anderen CUL. Alle resettet und neu gepairt, AC hab ich auch bekommen.
Zu dem Zeitpunkt war auch kein anderes fhem mehr mit einem CUL online.
Internals:
CFGFN
CULMAX0_MSGCNT 7
CULMAX0_TIME 2020-01-30 10:35:02
DEF HeatingThermostat 18acec
FUUID 5e328478-f33f-a5e8-8a55-7954e49c8ec1faad
FVERSION 10_MAX.pm:?/2020-01-29 UNSTABLE
IODev CULMAX0
LASTInputDev CULMAX0
MSGCNT 7
NAME hkAnkleide
NR 576
NTFY_ORDER 50-MAX_18acec
STATE 17.5°C
TYPE MAX
TimeSlot 2
addr 18acec
devtype 1
type HeatingThermostat
READINGS:
2020-01-30 08:23:36 PairedTo 000000
2020-01-30 10:35:02 RSSI -50.5
2020-01-30 08:23:36 SerialNr OEQ1133534
2020-01-30 10:35:02 battery ok
2020-01-30 10:35:02 batteryState ok
2020-01-30 08:23:37 boostDuration 25
2020-01-30 08:23:37 boostValveposition 80
2020-01-30 08:23:37 comfortTemperature 21.0
2020-01-30 08:23:37 decalcification Sat 12:00
2020-01-30 10:35:02 desiredTemperature 17.5
2020-01-30 09:58:15 deviation 2.0
2020-01-30 08:23:37 ecoTemperature 17.0
2020-01-30 08:23:37 error invalid or missing value for READING groupid
2020-01-30 08:23:36 firmware 1.0
2020-01-30 10:35:02 gateway 1
2020-01-30 08:23:37 groupid 0
2020-01-30 08:23:37 lastConfigSave 2020-01-30 08:23:37
2020-01-30 10:35:01 lastcmd set_desiredTemperature 17.5
2020-01-30 10:35:02 mapleCUN2_1_RSSI -100.5
2020-01-30 10:35:02 mapleCUN4_RSSI -81.5
2020-01-30 08:23:37 maxValveSetting 100
2020-01-30 08:23:37 maximumTemperature on
2020-01-30 08:23:37 measurementOffset 0.0
2020-01-30 08:23:37 minimumTemperature off
2020-01-30 10:35:02 mode manual
2020-01-30 10:35:02 panel locked
2020-01-30 09:58:15 peerIDs 000000
2020-01-30 09:58:15 peerList Broadcast
2020-01-30 10:35:02 rferror 0
2020-01-30 10:35:02 state 17.5°C
2020-01-30 09:58:15 temperature 20.0
2020-01-30 08:23:36 testresult 160
2020-01-30 08:23:37 valveOffset 0
2020-01-30 10:35:02 valveposition 0
2020-01-30 08:23:37 weekprofile-0-Sat-temp 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-0-Sat-time 00:00-06:00 / 06:00-22:00 / 22:00-24:00
2020-01-30 08:23:37 weekprofile-1-Sun-temp 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-1-Sun-time 00:00-06:00 / 06:00-22:00 / 22:00-24:00
2020-01-30 08:23:37 weekprofile-2-Mon-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-2-Mon-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-3-Tue-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-3-Tue-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-4-Wed-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-4-Wed-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-5-Thu-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-5-Thu-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-6-Fri-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-6-Fri-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 windowOpenDuration 15
2020-01-30 08:23:37 windowOpenTemperature 12.0
helper:
io:
mapleCUN2_1:
raw Z0E02020218ACEC1234560001390023
rssi -50.5
time 1580376902.21746
mapleCUN4:
raw Z0E02020218ACEC1234560001390023
rssi -81
time 1580376902.34462
internals:
interfaces thermostat;battery;temperature
Attributes:
CULdev mapleCUN2_1
IODev CULMAX0
debug 1
model HeatingThermostat
mqttPublish *:topic={"$base/$device/$name"}
room 2_Ankleide
schön du siehst das dein mapleCUN2_1 eindeutig besser ist als dein mapleCUN4
aber, wie gesagt das HT ist nicht gepaired , sieht man auch an :
2020-01-30 10:35:01 lastcmd set_desiredTemperature 17.5
und
2020-01-30 09:58:15 peerIDs 000000
2020-01-30 09:58:15 peerList Broadcast
das set_ sagt das du das möchtest , wenn es aber vom HT mit einem Ack bestätigt worden wäre stünde da
lastcmd desiredTemperature 17.5 (also ohne set_)
Daher nochmal das repairing am HT anwerfen mit Knöpfchen drücken, pairmode am CUL_MAX kann aus bleiben
One step further. Aber immer noch nicht weit genug. Der Thermostat hört aber trotzdem auf mich bzgl. desiredTemp. und maxValve
Internals:
CFGFN
CULMAX0_MSGCNT 13
CULMAX0_TIME 2020-01-30 11:29:49
DEF HeatingThermostat 18acec
FUUID 5e328478-f33f-a5e8-8a55-7954e49c8ec1faad
FVERSION 10_MAX.pm:?/2020-01-29 UNSTABLE
IODev CULMAX0
LASTInputDev CULMAX0
MSGCNT 13
NAME hkAnkleide
NR 576
NTFY_ORDER 50-MAX_18acec
STATE 18.0°C
TYPE MAX
TimeSlot 2
addr 18acec
devtype 1
type HeatingThermostat
READINGS:
2020-01-30 11:27:26 PairedTo 123456
2020-01-30 11:29:49 RSSI -51
2020-01-30 11:27:26 SerialNr OEQ1133534
2020-01-30 11:29:49 battery ok
2020-01-30 11:29:49 batteryState ok
2020-01-30 08:23:37 boostDuration 25
2020-01-30 08:23:37 boostValveposition 80
2020-01-30 08:23:37 comfortTemperature 21.0
2020-01-30 08:23:37 decalcification Sat 12:00
2020-01-30 11:29:49 desiredTemperature 18.0
2020-01-30 11:29:49 deviation 0.8
2020-01-30 08:23:37 ecoTemperature 17.0
2020-01-30 08:23:37 error invalid or missing value for READING groupid
2020-01-30 11:27:26 firmware 1.0
2020-01-30 11:29:49 gateway 1
2020-01-30 08:23:37 groupid 0
2020-01-30 08:23:37 lastConfigSave 2020-01-30 08:23:37
2020-01-30 11:27:43 lastcmd set_desiredTemperature 18.0
2020-01-30 11:29:49 mapleCUN2_1_RSSI -101
2020-01-30 11:29:49 mapleCUN4_RSSI -81.5
2020-01-30 08:23:37 maxValveSetting 100
2020-01-30 08:23:37 maximumTemperature on
2020-01-30 08:23:37 measurementOffset 0.0
2020-01-30 08:23:37 minimumTemperature off
2020-01-30 11:29:49 mode manual
2020-01-30 11:29:49 panel unlocked
2020-01-30 11:29:49 peerIDs 000000
2020-01-30 11:29:49 peerList Broadcast
2020-01-30 11:29:49 rferror 0
2020-01-30 11:29:49 sendTo_Broadcast 3
2020-01-30 11:29:49 state 18.0°C
2020-01-30 11:29:49 temperature 18.8
2020-01-30 11:27:26 testresult 160
2020-01-30 08:23:37 valveOffset 0
2020-01-30 11:29:49 valveposition 1
2020-01-30 08:23:37 weekprofile-0-Sat-temp 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-0-Sat-time 00:00-06:00 / 06:00-22:00 / 22:00-24:00
2020-01-30 08:23:37 weekprofile-1-Sun-temp 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-1-Sun-time 00:00-06:00 / 06:00-22:00 / 22:00-24:00
2020-01-30 08:23:37 weekprofile-2-Mon-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-2-Mon-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-3-Tue-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-3-Tue-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-4-Wed-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-4-Wed-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-5-Thu-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-5-Thu-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 weekprofile-6-Fri-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2020-01-30 08:23:37 weekprofile-6-Fri-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-24:00
2020-01-30 08:23:37 windowOpenDuration 15
2020-01-30 08:23:37 windowOpenTemperature 12.0
helper:
io:
mapleCUN2_1:
raw Z0F00046018ACEC0000000019012400BC
rssi -51
time 1580380189.53921
mapleCUN4:
raw Z0F00046018ACEC0000000019012400BC
rssi -81.5
time 1580380189.707
internals:
interfaces thermostat;battery;temperature
Attributes:
CULdev mapleCUN2_1
IODev CULMAX0
debug 1
model HeatingThermostat
mqttPublish *:topic={"$base/$device/$name"}
room 2_Ankleide
hmm , PairedTo hat jetzt schon mal deine 123456 und die ID hat auch der mapleCUN2_1 ?
Mich wundert halt das bei lastcmd wieder set_ steht und keine positive Quittung.
mapleCUN2_1 und mapleCUN4 sind die einzigen beiden CULs die in deinem Haus im rfmode MAX laufen ?
und jeder CUL hat eine eigene maxid ?
Die beiden CULs sind die einzigen mit MAX, aber die haben beide 123456.
Ist das schlimm? Hatte dich vorhin so verstanden, dass es so besser wäre.
Internals:
CMDS CAZNELYVXfz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF mapleCUN3
FUUID 5da3f7e5-f33f-a5e8-0f24-1371340e091b15ff
IODev mapleCUN3
NAME mapleCUN4
NOTIFYDEV mapleCUN3
NR 96
NTFY_ORDER 50-mapleCUN4
PARTIAL
RAWMSG Z0B04063018CCA612345600100F
RSSI -66.5
STATE Initialized
StackLevel 3
TYPE STACKABLE_CC
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_8F (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
mapleCUN4_MSGCNT 614
mapleCUN4_TIME 2020-01-30 14:02:18
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-01-30 08:15:34 cmds C A Z N E L Y V X f z
2020-01-30 13:46:23 credit10ms 3272
2020-01-30 14:02:18 state Initialized
Attributes:
maxid 123456
model CUN
rfmode MAX
room CUL_MAX
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXeflptxz*
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.1.241:2323 1423
DeviceName 192.168.1.241:2323
FD 94
FHTID 1423
FUUID 5e32758e-f33f-a5e8-ec42-5be8528261d63fed
NAME mapleCUN2_1
NR 235
NR_CMD_LAST_H 12
PARTIAL
RAWMSG H431000690153FF
RSSI -74.5
STACKED mapleCUN2_2
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_83 (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
mapleCUN2_1_MSGCNT 11209
mapleCUN2_1_TIME 2020-01-30 14:02:54
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-01-30 08:15:35 cmds B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
2020-01-30 14:02:05 credit10ms 3600
2020-01-30 14:02:54 state Initialized
XMIT_TIME:
1580386570.23924
1580386571.7798
1580386578.28588
1580386584.79207
1580386591.29816
1580386863.56293
1580387449.35975
1580387522.28287
1580387704.85527
1580388846.69656
1580388951.64849
1580389325.06437
Attributes:
maxid 123456
model CUN
rfmode MAX
room CUL_MAX
Darf ich mich in eure Unterhaltung einmischen? :D
Zitat von: Wzut am 30 Januar 2020, 12:50:36
Mich wundert halt das bei lastcmd wieder set_ steht und keine positive Quittung.
Bei mir laufen 1 WT und 3 HT's über einen CUL und 3 HT's über einen 2. CUL. Beide CUL's sind in einem CUL_MAX definiert. Auch ich habe an allen HT's bei lastcmd "set_" stehen...
Zitat von: Wzut am 30 Januar 2020, 12:50:36
und jeder CUL hat eine eigene maxid ?
Vielleicht liegt hier mein Fehler. Meinem CUL_MAX habe ich die Adresse 080352 gegeben und diese Adresse habe ich bei beiden CUL's als maxid eingetragen. Ist das falsch? Weil du schreibst, dass jeder CUL eine eigene maxid bekommt...
[Edit]
Sehe gerade, dass Maui es genauso verstanden hat...
Zitat von: Plextor am 30 Januar 2020, 14:06:51
Sehe gerade, dass Maui es genauso verstanden hat...
Gut dann kann ich euch auch gemeinsam antworten : alles richtig so :)
Wenn beide CULs die gleiche maxid haben könnt ihr jederzeit das CULdev an einem Device ändern, falls ihr feststellen solltet das eure erste Wahl vllt. nicht die Beste war. Irgendwann soll das aber mal quasi automatisch wie bei HM laufen, d.h. man gibt ein primäres Device (CUL) an aber wenn dies nicht erreichbar sein sollte oder ein anderes besser wechselt das System von sich aus.
Das mit den zwei IDs geht auch, ich sehe darin mehr Nach als Vorteile, aber wenn jetzt jemand sagt mein aktives System läuft mit iD 123456 und ich möchte da noch etwas ganz autarkes zum testen und spielen haben dann nimmt man für das zweite System eben eine andere ID
Thema set_ : welche Beta bzw wann habt ihr beide sie heruntergeladen ? die aktuelle Version müsste von Sonntag Abend sein.
Ich hab gestern die neusten gezogen, also ja sind aktuell.
Ich wiederhole mich zwar, aber danke für das maintainen von MAX. Du hauchst dem ganzen wieder leben ein.
Ich behaupte, dass die hw nicht viel schlechter ist als HM, aber der SW Part bzw. auch in fhem war halt nicht vergleichbar. Und da sind wir (du) grad auf dem besten Weg hin.
THX, aber ein Hardware Manko gegenüber Homematic wird bleiben : bei HM kann man via Funk die internen Register lesen und ich kann bei HM mehr Geräte untereinander verheiraten als bei MAX mit seinen drei Gerätegruppen WT , HT & FK
Aber wenn ich es auf die reine Heizfunktion runterbreche : MAX reichte bisher fast .. fast wegen dem einen IO der eben nicht das ganze Haus abdeckt.
D.h. für mich : ich bleibe dabei und werde jetzt die letzen Ecken doch noch nachrüsten nachdem ich jetzt zwei/drei CULs im Haus verteilen kann.
Aber anyway, ich muss meine Testinsel am Wochenende mal wieder auf euren Stand bringen und schauen warum sich lastcmd bei euch anderes verhält als bei mir.
Bei mir auch IMHO die aktuelle Version:
FVERSION 14_CUL_MAX.pm:?/2020-01-27 UNSTABLE
Obwohl ... der 27.01. war Montag und nicht Sonntag...
Auch von mir nochmal ein großes Dankeschön. Deine Beta läuft hier um Welten besser als die "offizielle".
@Wzut:
Ich habe noch ein bisschen gespielt und dabei folgendes festgestellt: Es scheint nur bei set desiredTemperature Probleme zu geben. Bei allen anderen set-Kommandos erscheint im lastcmd-Reading kurz set_[Kommando] und springt schnell um auf [Kommando]. Nur bei set desiredTemperature passiert im lastcmd-Reading zunächst gar nichts, erst ein Refresh der Seite zeigt dann im Reading set_desiredTemperature und ändert sich auch nicht bis zum nächsten anderen set-Befehl. Der eigentliche Befehl wird aber korrekt ausgeführt und ändert die Temperatur wie gewünscht.
Vielleicht hilft dir das bei der Suche...
@Plextor, THX !
ist unglaublich , ich habe mal wieder bei mir gesehen was ich sehen wollte ... :(