Ähm, komme grade noch nicht mit. Das eBus_daemon_splitter-Template hatte ich damals mal so konzipiert, das scheint ja unverändert zu sein, und mir ist auch einigermaßen präsent, welche Devices es in etwa bei einer "klassischen Heizung" macht. Das "Zentraldevice" ist dann eigentlich nur eine Art "Statusdevice" für den daemon bzw. ESP, alle anderen Teilnehmer auf dem Bus sollten dann separate Devices ergeben.
Unklar ist mir, für was die Devices dann stehen, die "630" scheint irgendein Typ Brennwertkessel oä. zu sein. Soweit, so gut.
Was du jetzt gemacht hattest, war, das "bridgeing" zu "umgehen", indem du die readingList erweitert hattest, und alles in dem Statusdevice zu belassen. Kann man machen, für die Handhabung im Rahmen von Sprachsteuerung erscheint es mir einfacher, wenn jede Baugruppe eben ein eigenes Device ist.
Jetzt habe ich das Ding von neulich nochmal runtergestrippt, dass da nur noch das drin steht, was zu "hc" gehört - geht aber nur bei allem, was ich irgendwie halbwegs eindeutig zuordnen kann, nicht aber beim jsonMap, weil ich die Quelle der Readings nicht kenne.
Daher jetzt mal das als Zwischenergebnis (mit den weggelassenen homebridgeMappings, soweit nach den Tests möglich):
defmod MQTT2_ebusd_test MQTT2_DEVICE ebusd_hc
attr MQTT2_ebusd_test IODev ebusMQTT
attr MQTT2_ebusd_test alexaName EBUSHaZe
attr MQTT2_ebusd_test alias EBUSHaZe
attr MQTT2_ebusd_test autocreate 1
attr MQTT2_ebusd_test genericDeviceType thermostat
attr MQTT2_ebusd_test icon sani_boiler_temp
attr MQTT2_ebusd_test readingList
ebusd/hc/Mode:.* { json2nameValue($EVENT, 'Mode_', $JSONMAP) }\
ebusd/hc/Params:.* { json2nameValue($EVENT, 'Params_', $JSONMAP) }\
ebusd/hc/Status:.* { json2nameValue($EVENT, 'Status_', $JSONMAP) }\
ebusd/hc/Status16:.* { json2nameValue($EVENT, 'Status16_', $JSONMAP) }\
ebusd/hc/Params/get:.* get
attr MQTT2_ebusd_test homebridgeMapping TargetHeatingCoolingState=mode,values=OFF:OFF;;HEAT:HEAT;;ECO:ECO;;AUTO:AUTO;;COOL:OFF\
history:size=1024
attr MQTT2_ebusd_test jsonMap Status16_temp_value:measured-temp Status_2_value:desired-temp Mode_hcmode1_value:mode Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
attr MQTT2_ebusd_test setList getKnown:noArg ebusd/list onlyknown\
getAll:noArg ebusd/list\
Params ebusd/hc/Params/get\
mode:uzsuDropDown,ON,OFF,AUTO,ECO,LOW ebusd/hc/SetMode/set $EVTPART1\
MinVLTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetFlowTempMin/set $EVTPART1\
MaxVLTemp:uzsuDropDown,60,61,62,63,64,65,66,67,68,69,70 ebusd/hc/SetFlowTempMax/set $EVTPART1\
AussenAusTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetShutdownTemp/set $EVTPART1\
AbsenkTemp:uzsuDropDown,15,16,17,18,19,20,21,22,23,24,25 ebusd/hc/SetTempDesiredLow/set $EVTPART1\
desired-temp:uzsuDropDown,-,20,21,22,23,24,25,26,27,28 ebus/hc/SetTempDesired/set $EVTPART1
Grundsätzlich gebe ich dir aber recht, hier müßten noch ein paar andere mit überlegen, was wie Sinn macht, v.a. welche, die grade dabei sind, in das Thema einzusteigen und es "einfach" haben wollen.
Interessehalber: Hast du je was mit Wochenplänen gemacht? Ich habe mir einen Teil der dummy-Geschichte mal angesehen, bin aber nicht so recht schlau draus geworden und hatte am Ende nur den Eindruck, dass das eigentlich so nicht richtig funktionieren kann, schon alleine, weil Daten zu einem Zeitpunkt verwendet werden, zu dem sie noch gar nicht (aktuell) geliefert worden sind. Aber evtl. verstehe ich da auch was falsch...
