Hallo,
wie ich bekomme das HEX File von kc-GitHub/HM485-Lib auf einen uno? Mit der Arduino ide ja nicht. Avrdude?
Danke
Joachim
Hi,
ich glaube mich zu erinnern, dass ich das mal mit Avrdude gemacht hatte. Ich glaube auch, dass das Teil mit der Arduino IDE mitgeliefert wird.
Ansonsten gibt es noch das hier:
http://www.hobbytronics.co.uk/arduino-xloader
Gruß,
Thorsten
jepp, schönen Dank
...und ich suche immer noch einen Freiwilligen, der das Ding mal auf die neuen Libs portiert. Dann könnte man das ganze einfach mit der Arduino IDE übersetzen und hochladen.
Gruß,
Thorsten
Hi,
ja.... ich hab mal angefangen HBW-1W-T10 auf die aktuelle Lib zu portieren... eigentlich nur als "Nebenprodukt". :o
Ich brauche im Grunde einen Heizungsventilsteller... ausgehend von HBW_CC_VD2_FM. Dort werden Kanäle 'Keys' und 'Switches' benötigt, welche ja in der aktuellen lib existieren. Dazu noch Kanäle 1-wire TempSensors und PIDs.. welche es noch nicht gibt.
Eine neue 'Channel' Klasse für 1-wire Temperatur Sensoren ergibt ja schon fast den HBW-1W-T10... leider hänge ich grade an der Stelle die richtigen EEPROM Adressen zu ermitteln um die 1-wire Adresse im EEPROM zu speichern... :-[ Im Prinzip den hier gesetzten festen Offset zu ersetzen:
https://github.com/kc-GitHub/HM485-Lib/blob/thorsten/HBW-1W-T10/HBW-1W-T10.cpp#L132
Werde mir aber erst mal mit zwei Parametern 'address start' und 'address step' helfen...
Leider habe ich ein ähnliches Problem bei der Suche nach bereits vorhandenen 1-wire Adressen über alle Kanäle hinweg...
https://github.com/kc-GitHub/HM485-Lib/blob/thorsten/HBW-1W-T10/HBW-1W-T10.cpp#L164
Die Suche nach neuen 1-wire Sensoren muss wohl außerhalb der Temperatur Kanäle stattfinden. ???
Irgenwie hab ich noch nicht die richtige Struktur dafür... :)
Gruß,
Thomas
Zitat von: loetmeister am 03 April 2019, 23:42:42
Eine neue 'Channel' Klasse für 1-wire Temperatur Sensoren ergibt ja schon fast den HBW-1W-T10... leider hänge ich grade an der Stelle die richtigen EEPROM Adressen zu ermitteln um die 1-wire Adresse im EEPROM zu speichern... :-[ Im Prinzip den hier gesetzten festen Offset zu ersetzen:
Das ist doch im Prinzip dasselbe wie für alle anderen Kanaltypen auch, oder? Du musst auch hier eine fixe Anzahl an Kanälen vorsehen, die halt nicht unbedingt alle "gefüllt" sind. Der Rest geht dann so wir für Switches und Keys auch.
Zitat
Leider habe ich ein ähnliches Problem bei der Suche nach bereits vorhandenen 1-wire Adressen über alle Kanäle hinweg...
https://github.com/kc-GitHub/HM485-Lib/blob/thorsten/HBW-1W-T10/HBW-1W-T10.cpp#L164
Die Suche nach neuen 1-wire Sensoren muss wohl außerhalb der Temperatur Kanäle stattfinden. ???
Ja, klar. Das muss glaube ich ins Hauptprogramm, wo ja sämtliche Listen (Arrays von Kanälen) bekannt sind. Dort muss man dann nachsehen, ob die jeweilige Adresse schon in einem Kanal benutzt wird.
Gruß,
Thorsten
Hi,
hab mal die erste Version eingecheckt... Funktioniert bei mir mit zwei Sensoren. Ein bisschen aufräumen und optimieren ist noch nötig...
Verhalten sollte (fast?) dem bisherigen HBW-1W-T10 entsprechen, XML ist aber etwas anders.
Suche nach Sensoren erfolgt nur beim device reset, nicht über Konfig Taster.
https://github.com/loetmeister/HBWired/tree/master/HBW-1W-T10
Gruß,
Thomas
Zitat von: loetmeister am 10 April 2019, 20:02:16
Verhalten sollte (fast?) dem bisherigen HBW-1W-T10 entsprechen, XML ist aber etwas anders.
Dann sollte man das ggf. mit der Firmware-Version auseinanderdröseln. Ein Gerätetyp (also HBW-1W-T10) kann durchaus mehrere verschiedene XMLs haben.
Zitat
Suche nach Sensoren erfolgt nur beim device reset, nicht über Konfig Taster.
Das sollte auch ausreichend sein. Wenn man einen neuen Sensor dranbaut sollte man das Ding sowieso vorher von der Versorgungsspannung trennen.
Gruß,
Thorsten
Hi,
Stimmt, mehrere xml wären möglich... Dann nenne ich die neue "v1", das passt dann zur Hardware Version. Die ist in der alten xml auf 0 gesetzt.
Gruß,
Thomas
Hallo,
hab ein paar Ergänzungen gemacht und aufgeräumt... was leider (noch) nicht klappt, ist den Sensor eines Kanals über FEHM zu löschen... s.u.
https://github.com/loetmeister/HBWired/commit/048c450710427aa684f0ccec83e8336c4ca13b61
Änderungen:
- Nicht verbundene Sensoren liefern nun ERROR Temp nach drei fehlgeschlagenen Leseversuchen in folge, gleiches gilt für CRC Fehler. Die ERROR Temp wird nur einmal versendend (wenn send_..._interval aktiv ist)
- XML ist umbenannt und hat nun passende Hard- & Firmware Version.
- Verbundener Sensortyp wird als Reading angezeigt, z.B.: R-onewire_type ds18s20
Um den Sensortyp anzuzeigen, habe ich den folgende XML code eingebaut.
Die Anzeige funktioniert auch, leider werden nicht die Werte geschrieben, die ich brauche... bei "NOT_USED" wird der Wert "0" ins EEPROM geschrieben, bei "REMOVE_DEVICE" "4". Mapping "from" und "to" device habe ich alle Kombinationen durch... :-[
<parameter id="ONEWIRE_TYPE">
<logical type="option">
<option id="NOT_USED" default="true"/>
<option id="DS18B20"/>
<option id="DS18S20"/>
<option id="DS1822"/>
<option id="REMOVE_DEVICE"/>
</logical>
<physical size="1.0" type="integer" interface="eeprom">
<address index="+6.0"/>
</physical>
<conversion type="option_integer">
<value_map to_device="true" from_device="true" parameter_value="0" device_value="0xFF"/>
<value_map to_device="true" from_device="true" parameter_value="1" device_value="0x28"/>
<value_map to_device="true" from_device="true" parameter_value="2" device_value="0x10"/>
<value_map to_device="true" from_device="true" parameter_value="3" device_value="0x22"/>
<value_map to_device="true" from_device="false" parameter_value="4" device_value="0xFF"/>
</conversion>
</parameter>Im FHEM log steht nur:
HBW_1W_T10_HBW4073471_03: Set config HBW_1W_T10_HBW4073471_03:
onewire_type=4Selbst als einfacher "integer" Wert klappt das setzen über "NOT_USED" nicht.... nur wenn der Wert "255" direkt eingegeben wird... :o
<parameter id="ONEWIRE_TYPE">
<logical type="integer" min="0" max="255">
<special_value id="NOT_USED" value="255"/>
...
Gruß,
Thomas
Hallo,
habe mal ein wenig in FHEM/lib/HM485/Device.pm geschaut wie die Umwandlung funktioniert... müsste "dataConvertValue" sein, in meinem Fall ($convertConfig->{'type'} eq 'option_integer')
Ob das beim Schreiben der Device Konfig auch aufgerufen wird konnte ich nicht genau feststellen.... ::)
Habe stattdessen mal den log level hochgestellt.... onewire_type wird nicht übersetzt. Liegts an meiner XML oder der HM485 FHEM lib? ;D
4: HBW_1W_T10_HBW4073471_02: HM485_SetConfig: name = HBW_1W_T10_HBW4073471_02 Key = send_delta_temp Wert = 0.50 msg =
4: HBW_1W_T10_HBW4073471_02: HM485_SetConfig: name = HBW_1W_T10_HBW4073471_02 Key = offset Wert = 0.00 msg =
4: HBW_1W_T10_HBW4073471_02: HM485_SetConfig: name = HBW_1W_T10_HBW4073471_02 Key = send_min_interval Wert = 10 msg =
4: HBW_1W_T10_HBW4073471_02: HM485_SetConfig: name = HBW_1W_T10_HBW4073471_02 Key = send_max_interval Wert = 150 msg =
4: HBW_1W_T10_HBW4073471_02: HM485_SetConfig: name = HBW_1W_T10_HBW4073471_02 Key = onewire_type Wert = 4 msg =
3: HBW_1W_T10_HBW4073471_02: Set config HBW_1W_T10_HBW4073471_02: send_delta_temp=0.50
5: HBW_1W_T10_HBW4073471_02: HM485_SetConfig fuer HBW_1W_T10_HBW4073471_02 Schreiben Eeprom 42FFFFFF_02 57 0015 01 05
5: HBW_1W_T10_HBW4073471: HM485_SendCommand: 5700150105
3: HBW_1W_T10_HBW4073471_02: Set config HBW_1W_T10_HBW4073471_02: offset=0.00
5: HBW_1W_T10_HBW4073471_02: HM485_SetConfig fuer HBW_1W_T10_HBW4073471_02 Schreiben Eeprom 42FFFFFF_02 57 0016 01 7F
5: HBW_1W_T10_HBW4073471: HM485_SendCommand: 570016017F
3: HBW_1W_T10_HBW4073471_02: Set config HBW_1W_T10_HBW4073471_02: onewire_type=4
5: HBW_1W_T10_HBW4073471_02: HM485_SetConfig fuer HBW_1W_T10_HBW4073471_02 Schreiben Eeprom 42FFFFFF_02 57 001B 01 04
5: HBW_1W_T10_HBW4073471: HM485_SendCommand: 57001B0104
3: HBW_1W_T10_HBW4073471_02: Set config HBW_1W_T10_HBW4073471_02: send_max_interval=150
5: HBW_1W_T10_HBW4073471_02: HM485_SetConfig fuer HBW_1W_T10_HBW4073471_02 Schreiben Eeprom 42FFFFFF_02 57 0019 02 9600
5: HBW_1W_T10_HBW4073471: HM485_SendCommand: 570019029600
3: HBW_1W_T10_HBW4073471_02: Set config HBW_1W_T10_HBW4073471_02: send_min_interval=10
5: HBW_1W_T10_HBW4073471_02: HM485_SetConfig fuer HBW_1W_T10_HBW4073471_02 Schreiben Eeprom 42FFFFFF_02 57 0017 02 0A00
5: HBW_1W_T10_HBW4073471: HM485_SendCommand: 570017020A00
5: HBW_1W_T10_HBW4073471: HM485_SendCommand: 43
5: HBW_1W_T10_HBW4073471: HM485_DoSendCommand: hmwId = 42FFFFFF data = 5700150105 requestId = 202
5: HBW_1W_T10_HBW4073471: HM485_DoSendCommand: hmwId = 42FFFFFF data = 570016017F requestId = 203
5: HBW_1W_T10_HBW4073471: HM485_DoSendCommand: hmwId = 42FFFFFF data = 57001B0104 requestId = 204
5: HBW_1W_T10_HBW4073471: HM485_DoSendCommand: hmwId = 42FFFFFF data = 570019029600 requestId = 205
5: HBW_1W_T10_HBW4073471: HM485_DoSendCommand: hmwId = 42FFFFFF data = 570017020A00 requestId = 206
5: HBW_1W_T10_HBW4073471: HM485_DoSendCommand: hmwId = 42FFFFFF data = 43 requestId = 207
5: HBW_1W_T10_HBW4073471: setRawEEpromData: Start: 0015 Len: 01 Data: 05
5: HBW_1W_T10_HBW4073471: setRawEEpromData: Start: 0016 Len: 01 Data: 7F
5: HBW_1W_T10_HBW4073471: setRawEEpromData: Start: 001B Len: 01 Data: 04
5: HBW_1W_T10_HBW4073471: setRawEEpromData: Start: 0019 Len: 02 Data: 9600
5: HBW_1W_T10_HBW4073471: setRawEEpromData: Start: 0017 Len: 02 Data: 0A00
4: HBW_1W_T10_HBW4073471: HM485_UpdateConfigReadings called
PS: https://github.com/loetmeister/HBWired/tree/master/HBW-1W-T10 hat noch ein paar Verbesserungen & fixes erhalten.
Gruß,
Thomas
Zitat von: loetmeister am 14 April 2019, 17:24:59
Habe stattdessen mal den log level hochgestellt.... onewire_type wird nicht übersetzt. Liegts an meiner XML oder der HM485 FHEM lib? ;D
Das kann ich so aus dem Kopf nicht sagen, aber ich werd's mir mal ansehen. Momentan habe ich aber noch was anderes zu reparieren...
Gruß,
Thorsten
Hi,
hmmm... Das hier habe ich in ConfigurationManager.pm, sub convertSettingsToEepromData gefunden:
if ($configData->{$config}{'config'}{'logical'}{'type'} &&
$configData->{$config}{'config'}{'logical'}{'type'} eq 'option') {
} else {
$value = HM485::Device::dataConversion(
$value, $configData->{$config}{'config'}{'conversion'}, 'to_device'
);
}
D.h. das, was beo conversion definiert ist, wird nicht durchlaufen, wenn es ein logical-Tag mit type=option gibt. Ich habe aber momentan keine Ahnung, warum das sinnvoll sein könnte. Wer weiß...
Ich muss mir das nochmal durch den Kopf gehen lassen. Vielleicht kann man das ja rauswerfen.
Gruß,
Thorsten
Hi Thorsten,
super, danke. Wenn ich zum testen diesen Teil auskommentiere funktioniert es wie erwartet. :D
logical type="option" scheint in der Tat selten einen "conversion" Element zu haben... ob man es deshalb einfach ignorieren kann? ;)
Aktuelle XML + Fixes:
https://github.com/loetmeister/HBWired/tree/master/HBW-1W-T10
Gruß,
Thomas
Zitat von: loetmeister am 26 April 2019, 00:25:26
super, danke. Wenn ich zum testen diesen Teil auskommentiere funktioniert es wie erwartet. :D
logical type="option" scheint in der Tat selten einen "conversion" Element zu haben... ob man es deshalb einfach ignorieren kann? ;)
Wahrscheinlich war das schon so, bevor ich es damals übernommen hatte.
Ich habe jetzt mal nachgesehen, wo das in den Standard-XMLs vorkommt. Das gibt es wohl nur bei SHORT_TOGGLE_USE und LONG_TOGGLE_USE. Kannst Du mal nachsehen, ob die entsprechende (Standard-)Geräte hast und das mal ausprobieren?
Gruß,
Thorsten
Hi,
Standard-Geräte habe ich nicht. Könnte aber eine XML erstellen und schauen was FHEMins EEPROM schreibt...
<parameter id="SHORT_TOGGLE_USE">
<logical type="option">
<option id="DONT_USE" default="true"/>
<option id="DIRECT"/>
<option id="INVERTED"/>
</logical>
<physical type="integer" size="0.2" interface="eeprom">
<address index="+6.4"/>
</physical>
<conversion type="option_integer">
<value_map device_value="0x03" parameter_value="0" from_device="true" to_device="true"/>
<value_map device_value="0x02" parameter_value="1" from_device="true" to_device="true"/>
<value_map device_value="0x00" parameter_value="2" from_device="true" to_device="true"/>
</conversion>
</parameter>
Gruß,
Thomas
Zitat von: loetmeister am 29 April 2019, 16:02:54
Standard-Geräte habe ich nicht. Könnte aber eine XML erstellen und schauen was FHEMins EEPROM schreibt...
Das hilft nicht wirklich viel. Es kommt mir darauf an, für die Standard-Geräte nichts kaputt zu machen. ...und da würde ich es gerne wirklich mit "echten" Geräten getestet haben. Vielleicht komme ich da mal nächste Woche oder so dazu, oder jemand liest hier mit, der das ausprobieren kann.
Freiwillige vor...
Gruß,
Thorsten
Hi,
habe das Problem bzgl. der Umwandlung, wie vorgeschlagen, mal hier festgehalten:
EEPROM erhält falsche Werte, da conversion "to_device" nicht beachtet wird #64
https://github.com/kc-GitHub/FHEM-HM485/issues/64
Habe noch ein weiteres Issue erstellt:
Speichern von "NOT_USED" in der Konfiguration nicht möglich #65
https://github.com/kc-GitHub/FHEM-HM485/issues/65
Gruß,
Thomas
hallo -
ich bin recht neu hier - ich habe es mal geschafft mit einem Arduino Nano den HBW_1W_T10 zusammen zu basteln... Nur leider will meine CCU2 nix von ihm wissen...
Im Seriellen Monitor sehe ich die Bus Kommunikation und dass mein HWB_1W_T10 auch was sendet, wenn ich auf die Taste drücke (FD:FF:FF:FF:FF:F8:42:FF:FF:FF:12:41:00:81:01:00:03:48:42:57:34:30:37:33:34:37:31:0E:52)
Wenn ich andere HM-Wired komponenten ansteuere kann ich die Kommunikation auch mitlesen.
Da es wahnsinnig viele verschiedene Versionen der HBW_1W_T10 gibt weis ich natürlich nicht ob es die richtige ist. Welche ist die aktuellste die auch auf der CCU2 funktioniert?
Danke für EUre Hilfe
lg
ANdi
Hi,
Welche Version hast du denn benutzt?
Würde empfehlen das repository von Thorsten zu nehmen... Bitte die komplette library nehmen, nicht nur den sketch vom device. 8)
https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10
Gruß,
Thomas
Hallo -
hab jetzt das komplette Repo von THorsten genommen.
Die Libs genommen, den Sketch neu kompiliert. AUf den Arduino hochgeladen.
Das gleiche wie vorher: Debug Output sehe ich, die CCU sieht den HBW-1w-T10 nicht.
Was mach ich falsch?
Danke für die Hilfe
lg
Zitat von: Sandomor am 05 Juli 2019, 08:47:40
Was mach ich falsch?
Du verwendest eine CCU und nicht FHEM...
Könntest Du das ganze mal mit FHEM versuchen? Da können wir vielleicht eher helfen und wenn es dann damit klappt, dann wissen wir, dass es nicht an der Arduino-Seite liegt.
Ansonsten: Welches Gateway verwendest Du, welchen "Abschluss"-Widerstand, hast Du das XML an die richtige Stelle in der CCU kopiert? ...CCU durchgestartet?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 05 Juli 2019, 09:25:25
Du verwendest eine CCU und nicht FHEM...
Könntest Du das ganze mal mit FHEM versuchen? Da können wir vielleicht eher helfen und wenn es dann damit klappt, dann wissen wir, dass es nicht an der Arduino-Seite liegt.
Ansonsten: Welches Gateway verwendest Du, welchen "Abschluss"-Widerstand, hast Du das XML an die richtige Stelle in der CCU kopiert? ...CCU durchgestartet?
Gruß,
Thorsten
Da ein ganzes Haus auf der CCU hängen hab, würde ich gerne dabei bleiben ;)
Für Tests kann ich mir natürlich ein FHEM aufsetzen - muss ich mich aber auch erst einarbeiten...
Ich verwende das "orginal" Homematic Gateway(HMW-LGW-O-DR-GS-EU) mit Abschlußwiderstand, sowie 2 weiteren Aktoren von Homematic, welche auch an der CCU funktionieren und ich im Seriellen Monitor auch die Daten mitlesen kann.
Das XML File hbw_1w_t10_v1.xml liegt in /firmware/hs485types und die CCU ist neu gestartet. Die CCU hat die Firmware Version 2.47.12.
Im Log der CCU kommen folgende Zeilen, nachdem ich den Taster kurz drücke (jetzt sollte ja eigentlich die CCU Notiz vom neuen Aktor nehmen):
Jul 5 09:46:14 homematic-ccu2 user.debug multimac: C> @4014157: #58 LLMAC RX @11937ms -55dBm 9B 84 70 5A 43 FB 00 00 00 00 EF 32
Jul 5 09:46:14 homematic-ccu2 user.debug multimac: Bidcos RX: #9B[BC|Ren] 5A43FB->000000 WeatherData: 00 EF 32
Jul 5 09:46:14 homematic-ccu2 user.debug multimac: GetAckActionForIncomingTelegram(): Unknown peer, AckAction_NotForUs
Jul 5 09:46:14 homematic-ccu2 user.debug multimac: A<: #254 HmBidcos RxTelegram AuthNone #9B[BC|Ren] 5A43FB->000000 WeatherData: 00 EF 32
Jul 5 09:46:15 homematic-ccu2 user.debug multimac: C> @4015295: #59 LLMAC RX @13081ms -57dBm 5A 84 70 45 8E 71 00 00 00 01 01 34
Jul 5 09:46:15 homematic-ccu2 user.debug multimac: Bidcos RX: #5A[BC|Ren] 458E71->000000 WeatherData: 01 01 34
Jul 5 09:46:15 homematic-ccu2 user.debug multimac: GetAckActionForIncomingTelegram(): Unknown peer, AckAction_NotForUs
Jul 5 09:46:15 homematic-ccu2 user.debug multimac: A<: #0 HmBidcos RxTelegram AuthNone #5A[BC|Ren] 458E71->000000 WeatherData: 01 01 34
Jul 5 09:46:16 homematic-ccu2 user.debug multimac: C> @4016422: #60 LLMAC RX @14213ms -41dBm 8D 86 70 50 2F CC 00 00 00 00 F1 2F
Jul 5 09:46:16 homematic-ccu2 user.debug multimac: Bidcos RX: #8D[BC|Ren|WMup] 502FCC->000000 WeatherData: 00 F1 2F
Jul 5 09:46:16 homematic-ccu2 user.debug multimac: GetAckActionForIncomingTelegram(): Unknown peer, AckAction_NotForUs
Jul 5 09:46:16 homematic-ccu2 user.debug multimac: A<: #2 HmBidcos RxTelegram AuthNone #8D[BC|Ren|WMup] 502FCC->000000 WeatherData: 00 F1 2F
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: C<: #165 TRX GetDutyCycle
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: C< @4016810: bin:FD 00 03 01 A5 03 46 17
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: C> @4016913: #165 TRX Response Ack 00
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: SubsystemBidcos::CheckDutyCycleEventThreshold( 0.0, 0.0 ) = 0
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: C> @4017020: #61 LLMAC RX @14813ms -60dBm 25 86 10 35 77 86 00 00 00 0A AC E7 11 00 40
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: Bidcos RX: #25[BC|Ren|WMup] 357786->000000 Info: 0A AC E7 11 00 40
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: GetAckActionForIncomingTelegram(): Unknown peer, AckAction_NotForUs
Jul 5 09:46:17 homematic-ccu2 user.debug multimac: A<: #5 HmBidcos RxTelegram AuthNone #25[BC|Ren|WMup] 357786->000000 Info: 0A AC E7 11 00 40
Jul 5 09:46:18 homematic-ccu2 user.debug multimac: C> @4018159: #62 LLMAC RX @15957ms -45dBm F9 86 10 28 BA 0D 00 00 00 0A 90 F4 0E 00 00
Jul 5 09:46:18 homematic-ccu2 user.debug multimac: Bidcos RX: #F9[BC|Ren|WMup] 28BA0D->000000 Info: 0A 90 F4 0E 00 00
Jul 5 09:46:18 homematic-ccu2 user.debug multimac: GetAckActionForIncomingTelegram(): Unknown peer, AckAction_NotForUs
Jul 5 09:46:18 homematic-ccu2 user.debug multimac: A<: #7 HmBidcos RxTelegram AuthNone #F9[BC|Ren|WMup] 28BA0D->000000 Info: 0A 90 F4 0E 00 00
Vielleicht kannst Du ja was raus lesen...
lg& Danke
Andi
Zitat von: Sandomor am 05 Juli 2019, 09:47:53
Ich verwende das "orginal" Homematic Gateway(HMW-LGW-O-DR-GS-EU) mit Abschlußwiderstand, sowie 2 weiteren Aktoren von Homematic, welche auch an der CCU funktionieren und ich im Seriellen Monitor auch die Daten mitlesen kann.
Hi Andi,
du hast also noch zwei weitere HM wired Geräte an dem selben Bus? Deren Daten kannst auf dem HBW-1w-T10 sehen? Wenn das stimmt, dann scheint der Empfang schon mal zu klappen... :)
Zum senden gibt es noch einen extra 'enable' Pin, ist der korrekt angeschlossen? Kannst du am Gateway sehen (LED?) das etwas auf den Bus gesendet wird? (wenn du den 'Config' Taster am HBW-1w-T10 drückst)
Aus dem Log kann ich leider nix ablesen....Es kommen ein paar Messwerte von Temperatur-/Wettersensoren, per "Bidcos" sind glaube ich Funkkomponenten.
Ich will aber auch nicht ausschließen das im XML irgendwas nicht "CCU" kompatibel ist... kannst du sehen ob HBW-1w-T10 als Gerät geladen wurde? (die Konfig)
Gruß,
Thomas
Hi,
nun das TX dürfte auch funktionieren (Led am Gateway blinkt) und es ist richtig verdrahtet...
im Log findet sich folgendes:
Jul 7 15:45:53 homematic-ccu2 user.info hs485d: Using configuration file: /etc/config/hs485d.conf
Jul 7 15:45:53 homematic-ccu2 user.info hs485d: Lan Device Information: Protocol-Version: 1 Product-ID: eQ3-HMW-LGW Firmware-Version: 1.0.5 Serial Number: PEQ0170636
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_io_4_fm.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 1 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_generic.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 2 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_central.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 3 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_sen_sc_12_dr.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 4 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_io12_sw7_dr.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 5 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_lc_sw2_dr_V3_02.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 6 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_lc_dim1l_dr.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 7 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_io_4_fm_V3_02.xml
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Device 8 created
Jul 7 15:45:54 homematic-ccu2 user.debug hs485d: Reading file hmw_lc_bl1_dr.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 9 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hmw_lc_sw2_dr.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 10 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hmw_io_sr_fm.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 11 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hmw_lc_bl1_dr_V3_02.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 12 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hmw_io_12_fm.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 13 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hmw_io12_sw14_dr.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 14 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hmw_io12_sw7_dr_V3_02.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 15 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hbw_1w_t10.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 16 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Reading file hbw_1w_t10_v1.xml
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device 17 created
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: 17 devices found
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H16V0=hmw_io_4_fm_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H17V0=hmw_lc_sw2_dr_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H18V0=hmw_io12_sw7_dr_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H20V0=hmw_lc_dim1l_dr_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H21V0=hmw_lc_bl1_dr_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H22V0=hmw_io_sr_fm_hw0_unstable.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H25V0=hmw_sen_sc_12_dr_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H26V0=hmw_sen_sc_12_fm_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H27V0=hmw_io_12_fm_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: H28V0=hmw_io12_sw14_dr_hw0.hex(@0x77F0)
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: LoadDeviceList()
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device created: HMW-IO-12-Sw14-DR NEQ0906749
Jul 7 15:45:55 homematic-ccu2 user.debug hs485d: Device created: HMW-LC-Bl1-DR NEQ1826947
Die Konfigdatei wird geladen (also beide eigentlich ) - jedoch fehlt dann die Zeile mit dem hw0.hex...
hilft das weiter?
lg
Hi,
könntest du hbw_1w_t10.xml entfernen? Dort ist glaube ich keine Hard- und Softwareversion des Device hinterlegt. Eventuell sorgt das für einen Konflikt?
Für die Devices, mit ..._hw0.hex liegt auf der CCU vermutlich ein hex Datei der Firmware... für HBW-1w-T10 nicht.
Gruß,
Thomas
Hab ich entfernt - leider keine Änderung...
Hi,
soweit ich mich erinnere, sollte die CCU zumindest irgendwas erkennen, auch wenn gar keine passendes XML-Datei vorhanden ist. Dann wird es halt ein "generic" Device, mit dem man nichts machen kann, aber irgendwas sieht man dann trotzdem.
Zitat von: Sandomor am 04 Juli 2019, 12:16:39
Im Seriellen Monitor sehe ich die Bus Kommunikation und dass mein HWB_1W_T10 auch was sendet, wenn ich auf die Taste drücke (FD:FF:FF:FF:FF:F8:42:FF:FF:FF:12:41:00:81:01:00:03:48:42:57:34:30:37:33:34:37:31:0E:52)
Der serielle Monitor zeigt ja erstmal das an, was über die USB-Schnittstelle geht, an der der Arduino hängt. Das heißt ja noch lange nicht, dass auch tatsächlich was über den Bus geht. Ich glaube mich auch daran zu erinnern, dass es manchmal Probleme gab, etwas auf den Bus zu bekommen, wenn die USB-Verbindung zum PC noch steht. Hast Du es mal mit der Debug-Pinbelegung probiert?
Gruß,
Thorsten
Hallo Thorsten,
hallo Thomas,
klasse Arbeit von euch mal wieder! Leider habe ich den Beitrag erst jetzt entdeckt, sonnst hätte ich das gerne für euch auch getestet!
Ich wollte mir aktuell einen neuen HBW-1W-T10 bauen (so bin ich auch hier gelandet). Ist das hier soweit das man es verwenden kann?
Bin ich hier Richtig? Ist das der letzte Stand?
https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10
(https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10)
Vielen Dank
Hi,
Ja, der stand bei Thorsten im repository ist soweit aktuell. Ich hatte bei mir nur noch eine kleine Änderung an der xml vorgenommen, da es sonst eine Anpassung des HM Moduls in FHEM erfordert.
https://github.com/loetmeister/HBWired/tree/master/HBW-1W-T10
EDIT:
Bzgl. "Ist das hier soweit das man es verwenden kann?"
Würde sagen, ja. :) Funktion ist wie beim alten Gerät + ein paar Verbesserungen für CRC Fehler oder wenn ein oder mehrere Sensoren abgeklemmt werden. Ein wenig mehr Tests sind aber auf jeden Fall sinnvoll.
Was ich noch nicht gelöst habe (per Software), das ein Sensor fehlerhaft 85°C bei einem schlechten 1-wire Bus anzeigen kann.
Gruß,
Thomas
Hallo Thomas,
danke für dein Feedback. Habe mit jetzt einen auf einem Ardoino Nano zusammengebaut. Hängt auch schon am Bus und wurde soweit auch gleich erkannt.
Ich habe jetzt auch einen DS18B20 aufgelegt, allerdings funktioniert das erst mal nicht. Es wird weiterhin -273,15 angezeigt. Ich bin mir allerdings nicht sicher ob ich den richtig aufgelegt habe. Ich habe vom Sensor:
Gelb ->D10-OneWire
Rot -> auf 5V
Schwarz -> GND
Zwischen D10-OneWire und 5V habe ich noch einen Widerstand gesteckt (habe ich auch ohne probiert)
OK, habe das mit dem Reset überlesen! Jetzt wurde der erste Sensor auch erkannt.
Wie ist das mit dem onewire_type? Wird der automatisch erkannt, oder muss ich den eintragen? Da ist bei mir nichts passiert.
So, jetzt hängt auch schon ein zweiter Sensor dran. Aber muss ich immer nur einen Sensor dran hängen zum anlehnen? Mit mehreren gleichzeitig funktioniert das nicht?!
Zitat von: holzwurm83 am 01 September 2019, 12:29:48
Wie ist das mit dem onewire_type? Wird der automatisch erkannt, oder muss ich den eintragen? Da ist bei mir nichts passiert.
Also eigentlich sollte da automatisch etwas drinstehen. Man muss nur was eintragen, wenn man z.B. einen Sensor ersetzen will. (Siehe auch https://wiki.fhem.de/wiki/HBW-1W-T10).
Womöglich funktioniert das nach den Änderungen von Thomas etwas anders.
Zitat von: holzwurm83 am 01 September 2019, 13:45:08
So, jetzt hängt auch schon ein zweiter Sensor dran. Aber muss ich immer nur einen Sensor dran hängen zum anlehnen? Mit mehreren gleichzeitig funktioniert das nicht?!
Ich weiß zwar nicht genau, was Du meinst, aber es sollte alles auch mit mehreren Sensoren funktionieren. Du musst halt nach Änderungen an der Hardware immer mindestens einen Reset machen, so dass die Firmware neu startet. (Allerdings sollte man sowieso nicht daran rumbasteln, wenn die Versorgungsspannung anliegt. Also sollte sich das mit dem Reset sowieso erübrigen.)
Gruß,
Thorsten
Hallo,
in onewire_type wird aktuell der binäre Wert des Sensortyps angezeigt. (Bei einem "DS18B20" sollte es "40" sein). Diesen Teil der XML hatte ich wieder wie im Original abgeändert.
https://github.com/loetmeister/HBWired/blob/c398f0ec88392444303ab82f798e427de849f463/HBW-1W-T10/hbw_1w_t10_v1.xml#L122
Die schönere Version, mit einer Liste um direkt den namen anzuzeigen (z.B. DS18B20) funktioniert in der Darstellung in FHEM, um aber Einstellungen erfolgreich im Kanal ändern zu können müsstest du eine Datei in FHEM ändern... ::) https://github.com/kc-GitHub/FHEM-HM485/issues/64
Bzgl. dem 1-Wire Bus. Es sollten alle Sensoren auf einmal erkannt werden können.
Wenn du einen zweiten Sensor hinzufügst, der nicht erkannt wird, liefert dir der erste Sensor noch werte, oder "verschwindet" der ebenfalls? (Liefert -273,14 °C?) Wenn der bus komplette zusammenbricht, vermute ich der Pullup Widerstand hat nicht den richtigen Wert? (Zwischen D10-OneWire und 5V) - ich habe 4,7k Ohm genommen.
Auch brauchst du nur zwei Anschlüsse:
Gelb -> D10-OneWire
Schwarz -> GND
Gruß,
Thomas
Danke für euer Feedback.
Zitatin onewire_type wird aktuell der binäre Wert des Sensortyps angezeigt.
Das hat jetzt dann doch funktioniert und wurde auch erkannt.
ZitatBzgl. dem 1-Wire Bus. Es sollten alle Sensoren auf einmal erkannt werden können.
Das hat bei mir nicht funktioniert. Ich habe immer einen Sensor dran gehängt, einen Reset gemacht und in Fhem ein get config, da sonnst -273,15 angezeigt wurde. Vielleicht hätte ich noch länger warten müssen, aber ich habe auch noch einen HBW-1W-T10 von Dirk mit Thorstens Software. Da hatte ich die Schwierigkeiten nicht.
ZitatWenn du einen zweiten Sensor hinzufügst, der nicht erkannt wird, liefert dir der erste Sensor noch werte, oder "verschwindet" der ebenfalls?
Der erste war weiterhin da mit korrekten Werten, aber der zweite hat weiterhin das gleiche angezeigt wie vorher.
ZitatWenn der bus komplette zusammenbricht, vermute ich der Pullup Widerstand hat nicht den richtigen Wert? (Zwischen D10-OneWire und 5V) - ich habe 4,7k Ohm genommen
Ich hatte testweise einen und zwei davon, wie von dir beschrieben dran hängen.
ZitatAuch brauchst du nur zwei Anschlüsse:
Gelb -> D10-OneWire
Schwarz -> GND
Das hier habe ich noch nicht verstanden. Was mache ich den mit dem roten Kabel? Einfan nicht anschließen? Aktuell habe ich eine Leitung mit ca. 30 Metern liegen. Dort habe ich dann jeweils Parallel an verschiedenen Stellen die Sensoren aufgelegt, da ja eine Sternförmiges verlegen max. nur 2,5-3m haben darf.
Hi,
Zitat von: holzwurm83 am 03 September 2019, 20:58:14
Das hat bei mir nicht funktioniert. Ich habe immer einen Sensor dran gehängt, einen Reset gemacht und in Fhem ein get config, da sonnst -273,15 angezeigt wurde. Vielleicht hätte ich noch länger warten müssen, aber ich habe auch noch einen HBW-1W-T10 von Dirk mit Thorstens Software. Da hatte ich die Schwierigkeiten nicht.
Das kann ich mir grade nicht Erklären. :)
Kannst du einmal das
#define DEBUG_OUTPUT in "HBWOneWireTempSensors.h" setzen (einkommentieren) und die Software auf den Arduino laden? Dann solltest du im Seriellen Monitor sehen welche Sensoren bereits gepeichert wurden, welche Speicherplätze noch frei sind, etc.
Dann auch mal ein "Reset" machen - über den Config Taster, um alle Sensoren zu löschen. Beim anschließenden Neustart sollten alle wieder erkannt werden...
Das einzige was anders zur Software von Thorsten ist, dass nicht nach neuen Sensoren gesucht wird wenn man den Config Taster kurz drück (wenn auch die Announce Nachricht Versendet wird). Dafür wird nach Sensoren gesucht, wenn du die Konfiguration eines beliebigen Kanals Abspeicherst. Damit könntest du im laufenden Betrieb Sensoren hinzufügen. Wie Thorsten aber angemerkt hat, macht man das am besten im stromlosen Zustand. :)
Zitat
Das hier habe ich noch nicht verstanden. Was mache ich den mit dem roten Kabel? Einfan nicht anschließen? Aktuell habe ich eine Leitung mit ca. 30 Metern liegen. Dort habe ich dann jeweils Parallel an verschiedenen Stellen die Sensoren aufgelegt, da ja eine Sternförmiges verlegen max. nur 2,5-3m haben darf.
Ja, einfach Rot frei lassen. Der Arduino ist für parasitäre Spannungsversorgung konfiguriert.
Die maximalen Längen sind mir nicht bekannt, ich hatte aber mit ca. 20 Meter Koax-Kabel keine Probleme. Generell sollte es ein Bus sein, wie lang die Stichleitungen sein können muss man wohl testen.
Gruß,
Thomas
ZitatDann solltest du im Seriellen Monitor sehen welche Sensoren bereits gepeichert wurden, welche Speicherplätze noch frei sind, etc.
Sorry, was ich nicht klar geschrieben hatte, ist das ich jeden Sensor einzeln angelernt hatte von den in Summe sieben Stück habe und danach alle auf einmal angeschlossen habe. Es wurde alles gespeichert und funktioniert jetzt auch. Lediglich das anlernen war ein Gefummel. Ich habe noch neue Sensoren bestellt, mit denen ich das noch mal testen kann.
ZitatJa, einfach Rot frei lassen.
Ok, das werde ich auf jeden Fall einmal testen. War mir so nicht klar.
ZitatDie maximalen Längen sind mir nicht bekannt,
Ist hier beschrieben. Ganz unten.
https://wiki.fhem.de/wiki/1-Wire_Busverlegung (https://wiki.fhem.de/wiki/1-Wire_Busverlegung)
Zitat von: holzwurm83 am 03 September 2019, 22:06:15
Sorry, was ich nicht klar geschrieben hatte, ist das ich jeden Sensor einzeln angelernt hatte von den in Summe sieben Stück habe und danach alle auf einmal angeschlossen habe. Es wurde alles gespeichert und funktioniert jetzt auch. Lediglich das anlernen war ein Gefummel. Ich habe noch neue Sensoren bestellt, mit denen ich das noch mal testen kann.
Ok, das hatte ich aber auch so verstanden. Mein Beileid das es 7 Stück waren... :)
Mich würde interessieren wie die Debug Ausgabe aussieht, warum nach dem ersten Sensor die Suche abbricht...
Gruß,
Thomas
Hallo Thomas,
Ja, einfach Rot frei lassen. Der Arduino ist für parasitäre Spannungsversorgung konfiguriert.
Ich habe das gestern einmal umgeklemmt, allerdings hatte ich damit große Problem. Manche Sensoren haben zum Teil 85 Grad angezeigt und ander -273,1. Ich habe jetzt alles wieder mit drei Adern angeschlossen. Die Datenleitung muss ich wie auf dem Bild Durchschleifen, da es sonnst nicht funktioniert.
Das soll wohl auch bei den DS18B20 mit einer parasitären Spannungsversorgung sehr schwierig sein, da die Verkabelung in diesem Zusammenhang sehr anfällig ist.
Aktuell habe ich noch ein Problem mit dem Pull-up Widerstand. Ich habe einen 4,7K aufgelegt, was allerdings nicht funktioniert. Stecke ich einen zweiten parallel dazu funktioniert es wieder. Ich habe dann mal beide gemessen und habe eine 2,5K aufgelegt wonach der Bus wieder zusammengebrochen ist.
Hast du eine Idee wie ich das austarieren kann?
Hallo,
habe mir noch mal die Application note 4255 und die Datenblätter des DS1820 und DS18B20 angeschaut.
Im parasitären Modus sollte Vdd (rot, +) mit Masse verbunden werden. Ich hatte sie immer offen gelassen und keine Probleme, kann natürlich mit den Leitungslängen zusammen wirken.
Ansonsten sind DS1820 und DS18B20 gleich, was die max. Stromaufnahme betrifft: 1 bis 1,5mA "active". Der Application note zu folge, müsste der Pullup dann im Bereich von 1,5k bis 2k Ohm liegen. (siehe Anhang)
Wenn es bei dir mit 2 parallelen 4,7K geht (=2,35k Ohm) und mit 2,5k Ohm nicht mehr, dann hast du ja schon den passenden Wert gefunden. Ich würde dann sogar noch auf 2,2k oder 2k Ohm gehen.
Was aber alles nicht zu deinem Setup passt: Diese Pullup Details gelten meiner Ansicht nach nur für den parasitären Modus. Wenn du eine eigene Spannungsversorgung hast, dann wäre der Pullup 4,7k.
In diesem Fall sollte aber auch im HBW-1W-T10 der parasitären Modus deaktiviert werden.
Zeile 127 in
HBWOneWireTempSensors.cpp, write(0x44, 1) in write(0x44, 0) ändern:
ow->write(0x44, 1); // start conversion, with parasite power on at the endPS: Interssante Info im DS18B20 Datenblatt:
ZitatThe use of parasite power is not recommended for temperatures above +100°C since the DS18B20 may not be able to sustain communications due to the higher leakage currents that can exist at these temperatures. For applications in which such temperatures are likely, it is strongly recommended that the DS18B20 be powered by an external power supply.
Gruß,
Thomas
Es gibt übrigens auch DS18B20 Versionen die von Hause aus nur den parasitären Modus können (DS18B20-PAR) dort ist der Vcc Pin not connected.
Haben glaub ich den Buchstaben P hinten.
Meine Erfahrungen früher als ich einige DS18x20 im Betrieb hatte, der parasitäre Modus war bei Leitungslängen von einigen m nicht sauber hinzubekommen, deswegen bin ich irgendwann auf 3 Leitungen zurückgegangen.
Hallo,
hab gestern mal 10 DS18B20 angeschlossen... auf einem Steckbrett, daher keine Probleme mit der Leitungslänge. Im parasitären Modus wollten sie aber nicht... keine Sensoren gefunden. Mit 5V Versorgungsspannung und 4,7k ohm Pullup wurden aber alle 10 beim Start des HBW-1W-T10 erkannt und im EEPROM gespeichert.
Gruß,
Thomas
Hallo Thomas,
ich hatte letzte Woche (nach dem ich in der Woche davor einen Nano in den Himmel geschickt hatte und neue bestellen musste) die Debug Ausgabe einmal ausprobiert und es wurden dann auch alle Sensoren erkannt.
Ich habe auch meine Verkabelung noch mal sauber angeklemmt und Parasitär angeschlossen was nun doch funktioniert. Allerdings habe ich die Datenleitung nicht im Stern angeschlossen.
Ich muss allerdings ein geschirmtes Kabel verwenden und den Schirm auf GND legen, da ich sonnst Störungen auf dem Bus habe.
...was lange währt.
Zitat von: loetmeister am 02 Mai 2019, 20:51:14
habe das Problem bzgl. der Umwandlung, wie vorgeschlagen, mal hier festgehalten:
EEPROM erhält falsche Werte, da conversion "to_device" nicht beachtet wird #64
https://github.com/kc-GitHub/FHEM-HM485/issues/64
Das ist jetzt erledigt, so wie vorgeschlagen. Ich dachte erst, dass das Probleme machen könnte, aber die einzige Stelle bei den Standard-Devices, wo das vorkommt, ist bei den Peering-Parametern. Dort wird aber sowieso eine andere Routine verwendet (eigentlich blöd...), die es schon länger richtig macht.
Ich hatte mich doch etwas gewundert, warum das bei mir funktioniert hat.
Zitat
Habe noch ein weiteres Issue erstellt:
Speichern von "NOT_USED" in der Konfiguration nicht möglich #65
https://github.com/kc-GitHub/FHEM-HM485/issues/65
Das muss ich leider momentan noch in der Pipeline lassen und mir nochmal genauer anschauen.
Gruß,
Thorsten
Hallo Thorsten,
Danke. Da werde ich später mal ein Update in FHEM machen. :D
Gruß,
Thomas
Zitat von: loetmeister am 02 Mai 2019, 20:51:14
Habe noch ein weiteres Issue erstellt:
Speichern von "NOT_USED" in der Konfiguration nicht möglich #65
https://github.com/kc-GitHub/FHEM-HM485/issues/65
So, jetzt habe ich damit mal angefangen. Leider kann ich das momentan bei mir nicht testen, vor Allem weil es keine Standard-Devices gibt, die dieses Problem haben. ...und ich will jetzt in meiner Produktiv-Umgebung nichts verpfuschen.
Also, könntest Du mal die beiden angehängten Dateien in Deine FHEM-(Test-)Umgebung kopieren und ausprobieren? Die hm485.js gehört nach /opt/fhem/www/pgm2 und die ConfigurationManager.pm nach /opt/fhem/FHEM/lib/HM485.
Wenn alles gut läuft, dann müsste das Problem bis auf eine Kleinigkeit damit gelöst sein. Kannst Du das bestätigen?
So, die Kleinigkeit ist die Anzeige des R-Readings für float-Parameter. In Deinem Fall müsste das R-short_on_level sein. Kannst Du mal nachsehen, was da steht, nachdem Du OLD_LEVEL gesetzt hast?
Gruß,
Thorsten
Hi Thorsten,
danke für die Mühe.
Ich hatte zunächst ein "update" gemacht, danach neu gestartet und geschaut das FHEM soweit läuft.
Dann habe ich hm485.js und ConfigurationManager.pm mit deinen geänderten Versionen überschrieben.
Leider stimmt da was nicht:
2019.11.05 23:03:06 1: reload: Error:Modul 10_HM485 deactivated:
Global symbol "$sort" requires explicit package name (did you forget to declare "my $sort"?) at FHEM/lib/HM485/ConfigurationManager.pm line 319, <$fh> line 51.
Compilation failed in require at ./FHEM/10_HM485.pm line 33, <$fh> line 51.
BEGIN failed--compilation aborted at ./FHEM/10_HM485.pm line 33, <$fh> line 51.
In ConfigurationManager.pm habe ich wieder die gesicherte Version genommen. hm485.js habe ich belassen. Damit startet FHEM wieder...
Gruß,
Thomas
Hi,
ok, das war ein copy&paste-Fehler.
Bitte versuch's mit der hier dranhängenden Datei nochmal.
Gruß,
Thorsten
Hi Thorsten,
das sieht besser aus, teilweise kann ich eine Veränderung feststellen.
Wenn ich ein peering erstelle und versuche short_on_level auf old_level zu setzten, dann wird noch immer der Wert 200 (statt 201) geschrieben.
Set peerdetails: short_on_level=200
Beider der Kanalkonfiguration scheint es aber zu klappen, special_value wird genutzt:
Set config HBW_SD6_Multikey_v1_HBW0000999_25: send_min_interval=not_used
Gruß,
Thomas
Zitat von: loetmeister am 07 November 2019, 20:06:26
Wenn ich ein peering erstelle und versuche short_on_level auf old_level zu setzten, dann wird noch immer der Wert 200 (statt 201) geschrieben.
Set peerdetails: short_on_level=200
Das ist seltsam, weil das mit dem special_value bei Peerings bisher immer funktioniert hat.
...nach ein bisschen mehr Nachforschung: Wenn ich das hier ins Kommandofeld eingebe...
{ int(1.005 * 200) }
...dann kommt da 200 raus.
Das ist also ein Rundungsfehler.
Ich denke, dass ich das jetzt auch korrigiert habe. Bitte die angehängte Datei Device.pm nach /opt/fhem/FHEM/lib/HM485 und nochmal probieren.
Gruß,
Thorsten
Danke, special_value "1.005" funktioniert nun: 8)
Set peerdetails: short_on_level=201Nicht nur laut log, auch das peering macht nun was es soll ;)
(Der Rundungsfehler erklärt auch warum 1.01 -> 202 funktioniert hatte.)
Der Haken bei "old_level" in den Peering Details ist nicht gesetzt. Das hätte den Nachteil wieder den Standardwert zu schreiben, wenn man den Haken nicht jedes mal setzt (auch wenn man diese Option gar nicht verändern will)
special_value bei der Kanalkonfiguration war ja ok. Habe mal bei send_max_interval den log level erhöht:
HBW0000999_25: Set config HBW_SD6_Multikey_v1_HBW0000999_25: send_max_interval=not_used
HBW0000999_25: HM485_SetConfig fuer HBW_SD6_Multikey_v1_HBW0000999_25 Schreiben Eeprom 608 F40E7_25 57 0044 02 0000Das sieht ebenfalls gut aus.
Zitat[...]die Anzeige des R-Readings für float-Parameter. In Deinem Fall müsste das R-short_on_level sein. Kannst Du mal nachsehen, was da steht, nachdem Du OLD_LEVEL gesetzt hast?
Da stehe ich grade etwas auf dem Schlauch. Ein "list"auf den Kanal zeigt mir das nicht an... wo kann ich das sehen? Oder ist das die Einschränkung in der Darstellung, die du erwähnt hattest? (Haken bei "old_level" in den Peering Details)
Gruß,
Thomas
Zitat von: loetmeister am 07 November 2019, 22:28:15
Der Haken bei "old_level" in den Peering Details ist nicht gesetzt.
Das ist vermutlich auch wieder ein Rundungsfehler. Ich schau mir das auch noch an.
Zitat
Da stehe ich grade etwas auf dem Schlauch. Ein "list"auf den Kanal zeigt mir das nicht an... wo kann ich das sehen?
Die R-Readings gibt es bei Peering-Parametern nicht, sondern nur bei solchen, die direkt zum Device/Kanal gehören. Ich dachte ja vorher, dass wir über so etwas reden. D.h. Du kannst das ignorieren.
Gruß,
Thorsten
Hi,
ich glaube, dass ich jetzt auch herausgefunden habe, warum der Haken nicht gesetzt ist. Datei Device.pm, Zeile 1101/1102:
$retVal = $retVal / $factor;
$retVal = sprintf("%.2f", $retVal - $offset);
D.h. in Deinem Fall:
retVal = 201 / 200 = 1.005
...was dann aber auf 1.01 gerundet wird. Später wird das dann mit dem special_value=1.005 verglichen, was natürlich scheitert.
Ich könnte das jetzt theoretisch auf drei Nachkommastellen erweitern, aber das würde unter Umständen einige andere Änderungen nach sich ziehen. Außerdem würde es bei vielen anderen Feldern seltsam aussehen.
Könntest Du Dir vorstellen, auch mit zwei Nachkommastellen auszukommen? D.h. special_value=1.01 ? Das müsste doch auch gehen.
Könntest Du Dir das mal anschauen? Sollte das bei Dir auch viel Aufwand erzeugen, dann schaue ich mir's nochmal an.
Gruß,
Thorsten
Hi Thorsten,
Ok, danke. Das klingt etwas aufwändig.
Ich hatte diese Konfiguration, mit 1,005 aus der XML des homematic Funk dimmers übernommen...
Ich kann es aber auch auf 1,01 anpassen.
Gruß,
Thomas
Also wenn die CCU das kann, dann will ich das auch können. Ich schau mir das nochmal an.
Gruß,
Thorsten
Hi,
versuch mal die hier dranhängende Device.pm.
Wenn es klappt, dann wäre es nett, wenn Du Dir auch mal andere Parameter (bzw. Werte) anschaust, die ein float_integer_scale oder ein integer_integer_scale haben. (Wenn Du sowas hast.)
Zur Erklärung: Das Teil versucht jetzt, Zahlen, die mehr als 2 Nachkommastellen haben, auch so darzustellen. Das sollte bis 8 Nachkommastellen funktionieren. Dabei müssten aber solche Dreckeffekte wie "1.999999999999876" rausgefiltert werden, da das mit 8 Nachkommastellen auf 2.00000000 gerundet werden müsste. Eine Zahl, die dann mit weniger als 2 Nachkommastellen angezeigt werden kann, wird dann wieder auf 2 erweitert, um einigermaßen kompatibel zu vorher zu bleiben.
Gruß,
Thorsten
Hi,
Der Haken bei "old_level" in den Peering Details wird nun richtig angezeigt.
Bei anderen float_integer_scale Werten habe ich keine Änderung erkennen können. Die anzeige der Werte ist wie bisher.
Setzen neuer Werte geht auch (z.B. 91,5% -> 183)
Besonders ausgiebig habe ich aber nicht getestet.
Gruß,
Thomas
Hi Thorsten,
Lässt sich nicht der Code vom FHEM Modul für homematic Funk nutzen? Dort sollten diese Probleme doch schon gelöst sein?
Gruß,
Thomas
Zitat von: loetmeister am 10 November 2019, 00:50:50
Lässt sich nicht der Code vom FHEM Modul für homematic Funk nutzen? Dort sollten diese Probleme doch schon gelöst sein?
Ich habe mal versucht, das zu finden, aber vergeblich. Bist Du Dir sicher, dass das bei HM-Funk funktioniert?
Jedenfalls wäre es ziemlich aufwändig, das bei HM-Funk zu finden und wahrscheinlich würde das entsprechende Coding auch nicht wirklich passen.
Ich denke mal, das lasse ich lieber bleiben.
Gruß,
Thorsten
Hi,
ich habe jetzt den letzten Stand des HM485-Moduls ins Git hochgeladen. Damit müsste jetzt alles erledigt sein.
Gruß,
Thorsten
Hi,
ja danke, sieht gut aus. 8) Habe auch alle XML aktualisiert, die ONEWIRE_TYPE nutzen.
https://github.com/loetmeister/HBWired/commit/d805a9490ae80d89e12cab61614df7b100c7cc11
Gruß,
Thomas
Hallo Thomas,
hallo Thorsten,
ich habe leider aktuell immer wieder Aussetzer auf dem BUS. Ich habe die Vermutung das es von dem HBW-1W-T10 kommt. Die ausgespielte Firmware müsste so ca. zwei Jahre alt sein, bevor es diese Anpassungen hier gabt. Der Aktor ist 42000017 . Ich habe euch mal dem LOG angehängt. Könnt ihr euch das mal anschauen. Bis vor wenigen Wochen hatte ich eigentlich nicht wirklich Probleme.
Eine andere Frage hätte ich zur Definition des LOGs. Ich habe den wie folgt definiert:
attr HM485_LAN HM485d_logVerbose 5
attr HM485_LAN HM485d_logfile ./log/HM485-%Y-%W.log
Allerdings wird mir nun eine Datei erstellt die genau so heißt "HM485-%Y-%W.log" und nicht eine Datei pro Woche.
Hier ist die Datei:
https://we.tl/t-BzDbrJEYEh (https://we.tl/t-BzDbrJEYEh)
Hi,
könntest zu das log hier im Forum als Zip anhängen? In deinem Link sehe ich nur Werbemüll....
Bzgl. deinem Problem. Was für "Aussetzer" hast du denn? Woran zeigt sich das? Läuft alles problemlos ohne HBW-1W-T10? Was ist geändert worden, wenn "früher" alles ok war? :)
Gruß,
Thomas
Zitat von: loetmeister am 05 April 2021, 21:50:49
könntest zu das log hier im Forum als Zip anhängen? In deinem Link sehe ich nur Werbemüll....
Habe ich jetzt mal angehängt
Zitat von: loetmeister am 05 April 2021, 21:50:49
Bzgl. deinem Problem. Was für "Aussetzer" hast du denn? Woran zeigt sich das? Läuft alles problemlos ohne HBW-1W-T10? Was ist geändert worden, wenn "früher" alles ok war? :)
Die Aussetzer zeigen sich das die Geräte, die nicht direkt mit einander gepeert sind nicht reagieren. Z.B. ein Taster der nicht direkt gepeert ist lässt das Licht nicht einschalten. Der Tastendruck selbst zeigt sich in Fhem selbst auch nicht. Aus Fhem lässt sich das Licht direkt in dem Fall einschalten.
Komplett ohne HBW-1W-T10 habe ich das noch nicht ausprobiert, aber wenn ich den kurz vom Netz genommen habe ist alles wieder gelaufen.
Wobei ich das bis jetzt noch nicht so 100% rekonstruieren kann. Selbst wenn ich bei einem Aussetzer einfach nichts unternommen habe, ging auch nach einer Zeit alles wieder.
Ich habe einen MacMini Server auf dem Docker läuft. Fhem läuft in einem Container. Der Anfang ist mir nicht mehr ganz klar, aber ich meine das es angefangen hat als ich ein update für Docker gemacht habe.
Ich hatte heute die Vermutung das es evtl. was mit der Verbindung zum BUS selbst zu tun hat und ich evtl. noch einen extra Port freigeben muss. Habe jetzt heute mal noch den Port 2000 für den fhem Container freigegeben.
Hi,
das log geht über ein paar Tage.... wann gab es denn das Problem? ???
Was mit beim Überfliegen aufgefallen ist:
42000017 schickt komische Nachrichten an F1FFC703 und 07020017. Was sind das für Zielgeräte? Kannst du bei 42000017 mal alle peerings anzeigen?
608F3FAC schickt eine weile in Kurzer Folge Tastendrücke und Annonce Nachrichten. Ist das richtig? oder Hängt da ein Taster?
Gruß,
Thomas
Zitat von: loetmeister am 05 April 2021, 23:47:50
das log geht über ein paar Tage.... wann gab es denn das Problem? ??
Meistens am Abend. So kurz vor Mitternacht, aber das war nicht immer so. In dem Log müsste das auf jeden Fall Nachts passiert sein.
Zitat von: loetmeister am 05 April 2021, 23:47:50
42000017 schickt komische Nachrichten an F1FFC703 und 07020017. Was sind das für Zielgeräte?
Habe gerade einmal nachgeschaut. Ich habe werde ein HBW, noch ein HMW Gerät, dass so heißt.
Zitat von: loetmeister am 05 April 2021, 23:47:50
Kannst du bei 42000017 mal alle peerings anzeigen?
Habe dir dazu ein List angehängt. Ich habe für diese Gerät bislang auch keine Peers eingerichtet.
Zitat von: loetmeister am 05 April 2021, 23:47:50
608F3FAC schickt eine weile in Kurzer Folge Tastendrücke und Annonce Nachrichten. Ist das richtig? oder Hängt da ein Taster?
Da hängt ein IO-Modul dran:
http://www.haus-bus.de/index.php?showHtml=ioModul (http://www.haus-bus.de/index.php?showHtml=ioModul)
An dem ist ein SPS 6-Fachtaster angeschlossen und Bewegungsmelder.
Hi,
ok, den HBW-IO-12-1W-UP kenn ich... sollte ok sein, wenn der Melder richtig anspricht. Ich weiß nicht ob das den original HMW Geräten entspricht, aber immer eine Announce Nachricht mit zu senden fand ich nicht so gut. (für eine gepeerte Tasten sind das drei Nachrichten: announce, key press Broadcast und peering). Ist aber erst mal egal, denke ich....
bzgl. HBW-1W-T10. Im log ist ab 21:06 komisches zu sehen... habe den String mal etwas zerteilt, da es immer wieder die selben Zeichenfolgen sind....
2021.04.03 21:06:07.311 3: HM485d: Rx: I[2](0,Y,B)(8C) 42000017 -> F1FFC703 [185] 03()
2C03F123230006059503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F1232300060703C7FFF1EC069503
C7FFF1ECB797088F1B00230006069503
C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F1232300060703C7FFF1EC069503
C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F123230006069503C7FFF1ECB703
2C03F1232300060703C7 {EDF4}
2021.04.03 21:06:07.313 4: HM485d: Tx: FDC20065F1FFC7038C42000017032C03F123230006059503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F1232300060703C7FFF1EC069503C7FFF1ECB797088F1B00230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F1232300060703C7FFF1EC069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F123230006069503C7FFF1ECB7032C03F1232300060703C7
ganz ehrlich, ich wüsste nicht wie und warum HBW-1W-T10 so was raus schicken sollte... der Nachrichten Typ existiert nicht. Ich denke da kommen irgendwie Daten Pakete durcheinander.
Was mir ebenfalls schleierhaft ist, warum FEHM darauf antworten sollte "HM485d: Tx:"... wenn das Ziel "F1FFC703" war, dann wird es ja nicht von der Zentrale quittiert. Eventuell kann Thosten mehr zum Logging sagen.
Würde vorschlagen du läds dir die aktuelle lib und HBW-1W-T10 und aktualisiert das Gerät. Einstellungen und Sensoren sollte gespeichert bleiben. Zu Sicherheit vergleiche mal deine HBW-1W-T10 XML mit der von github. Ab ende 2019 gab es da keine Änderungen mehr, d.h. es hat sich nichts am EEPROM Layout geändert.
(https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10)
Edit:
Noch eine Ergänzung. Ich selber habe HBW-1W-T10 nicht im Einsatz, aber HBW-CC-DT3-T6 und HBW-CC-VD-8 welches den selben Code aus "HBWOneWireTempSensors.h" nutzt. Hab noch nicht beobachtet das der Bus mit Datenmüll geflutet wurde.... ::)
Gruß,
Thomas
Zitat von: loetmeister am 06 April 2021, 20:38:40
Würde vorschlagen du läds dir die aktuelle lib und HBW-1W-T10 und aktualisiert das Gerät. Einstellungen und Sensoren sollte gespeichert bleiben. Zu Sicherheit vergleiche mal deine HBW-1W-T10 XML mit der von github. Ab ende 2019 gab es da keine Änderungen mehr, d.h. es hat sich nichts am EEPROM Layout geändert.
(https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-1W-T10)
Ok, danke schon mal. Werde ich mal die Tage mal schauen, ob ich das mal aufspiele.
ZitatIn diesem Fall sollte aber auch im HBW-1W-T10 der parasitären Modus deaktiviert werden.
Muss ich dazu dann noch was umstellen? Ich habe das nicht im parasitären Modus laufen?
Wenn du die Sensoren mit +5V (neben Masse und dem Datenpin) verbunden hast, dann wäre es sauberer den parasitären Modus zu deaktivieren. Es läuft aber auch so..
HBWOneWireTempSensors.cpp Zeile 130.
(1 in 0 ändern oder den Parameter löschen...)
ow->write(0x44, 0);
Gruß,
Thomas
Hallo Thomas,
eine Update habe ich noch nicht durchführen können. Ich habe heute, aber einen kurzen Aussetzer auf dem BUS zeitlich sehr genau eingrenzen können. Wann es genau angefangen hat weiß ich nicht, aber um kurz vor 18Uhr ist es mir aufgefallen und ab 18 Uhr hat wieder alle Funktioniert.
Kannst du dir das im LOG nochmal anschauen ob dir was auffällt?
Danke dir.
Hi,
also das komische Verhalten was im vorigen Beitrag im log gesehen hatte sehe ich nicht... auch nichts was mit dem Gerät 42000017 zusammenhängt... aber es gibt mehrfach Pausen - bzw. unbekannte/unvollständige Kommunikation in ca. 20 Sekunden Intervallen. Irgendwie wird da hochgezählt... discovery kann es aber eigentlich nicht sein. Habe ich noch nicht gesehen....
EDIT: Es schein ein Keep alive vom hm485 FHEM Modul an den HM485d deamon zu sein. Also wenn sonst keine Kommunikation stattfindet wird so eine Art ping an den HM485d prozess geschickt, welche aber nicht auf den Bus geht (also Rx / Tx nur zwischen FHEM und HM485d)
Im FHEM log sieht man das.... hatte ich mir noch nicht so genau angeschaut ... ;D
2021.04.08 21:11:47 5: hm485: HM485_LAN_Write TX: 18
2021.04.08 21:11:47 5: SW: fd02124b
2021.04.08 21:11:47 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 18 Cmd: 97
2021.04.08 21:11:47 5: hm485: HM485_LAN_parseIncommingCommand: Alive: (18) 00 AliveStatus: 00
Die Frage bleibt... warum ist für über 30 Minuten ruhe auf dem Bus?
/EDIT
2021.04.08 17:25:08.693 4: HM485d: Rx: FD02714B
2021.04.08 17:25:08.697 4: HM485d: Tx: FD03716100
2021.04.08 17:25:28.706 4: HM485d: Rx: FD02724B
2021.04.08 17:25:28.709 4: HM485d: Tx: FD03726100
2021.04.08 17:25:48.715 4: HM485d: Rx: FD02734B
2021.04.08 17:25:48.718 4: HM485d: Tx: FD03736100
2021.04.08 17:26:08.724 4: HM485d: Rx: FD02744B
2021.04.08 17:26:08.727 4: HM485d: Tx: FD03746100
...
2021.04.08 17:59:50.025 4: HM485d: Rx: FD02D94B
2021.04.08 17:59:50.028 4: HM485d: Tx: FD03D96100
Immer von ca. 25 nach bis zur vollen Stunde. Gibt es da einen Bestimmen Task?
Hi,
das Logging sieht für mich ein bisschen danach aus, als ob da irgendein Gerät (oder etwas anderes) auf den Bus rausruft, ohne vorher zu prüfen, ob der Bus busy ist. So etwas in der Art könnte auch die vermeintliche Ruhe auf dem Bus erklären. Der Daemon versucht halt aus dem Datenmüll irgendwas rauszulesen, was er kennt.
Ich glaube, dass man da mal ein Gerät nach dem anderen zeitweise vom Bus nehmen muss und dann sieht, ob eins davon der "Übeltäter" ist.
Hast Du den so genannten "Busabschluss" bei Dir drin?
Gruß,
Thorsten
Hi,
Danke für euer Feedback!
Zitat von: loetmeister am 08 April 2021, 20:59:32
Immer von ca. 25 nach bis zur vollen Stunde. Gibt es da einen Bestimmen Task?
Muss ich mal auf den Grund gehen, aber ich wüste nicht was das sein sollte. Eine Pumpe im Garten Schaltet immer zur vollen Stunde ein für 15min.
Zitat von: Thorsten Pferdekaemper am 08 April 2021, 21:34:52
Ich glaube, dass man da mal ein Gerät nach dem anderen zeitweise vom Bus nehmen muss und dann sieht, ob eins davon der "Übeltäter" ist.
Ich habe aktuell eine Vermutung das es was mit dem 000094E5 zu tun hat. Das ist ein HMW_SEN_SC_12_DR. Da hängen die Fenster dran. Der Vorfall Heuft sich, wenn ein Fenster einmal offen war.
Zitat von: Thorsten Pferdekaemper am 08 April 2021, 21:34:52
Hast Du den so genannten "Busabschluss" bei Dir drin?
Ja, der ist verbaut. Ohne laufen nicht alle Autoren.
Hallo Thorsten,
hat mein Problem evtl. auch damit zu tun?
https://forum.fhem.de/index.php/topic,120277.0.html (https://forum.fhem.de/index.php/topic,120277.0.html)
Meine Fhem Version ist auch jeden Fall auf einem Stand von 2021.
Hi,
das glaube ich nicht wirklich, da Du ja dann auch die Meldungen aus dem anderen Thread sehen müsstest. Allerdings ist es tatsächlich etwas seltsam, dass Du die Meldung nicht siehst. Du kannst ja mal die im anderen Thread beschriebene Änderung einbauen und ausprobieren.
Gruß,
Thorsten
Hallo Thomas,
hallo Thorsten,
ich habe nun die Firmware des HBW-1W-T10 auf den aktuellen Stand gebracht und das aussetzten des Bus einige Wochen mal beobachtet.
Ich habe leider immer wieder den Fall (nicht täglich) das der Bus nicht reagiert und nach z.B. 15 Minuten wieder geht.
Des weiteren habe ich festgestellt das jeden Abend, wenn die Rollos anfangen runter zu fahren einzelne Aktoren für Sekunden ausfallen.
Könnt ihr euch noch mal den Log anschauen, ob euch dazu etwas auffällt?
Ich hatte mir schon überlegt, ob das Netzteil evtl. zu schwach ist, aber eigentlich habe ich das auf zwei aufgeteilt.
Hi,
also das ganze Log durcharbeiten kann ich nicht...
Was mir aber aufgefallen ist: Es gibt ein Device 608F3FC4, welches ziemlich of Key-Events "an alle" schickt (4B an FFFFFF) und danach jedesmal eine Announce-Message (41 an FFFFFF). Ich kann mir nicht vorstellen, dass das so sein soll. Ich glaube, dass das Device nicht gepairt ist. Schau mal, ob das die Zentrale kennt.
Könntest Du ansonsten mal genauer beschreiben, wie deine zwei Netzteile angeschlossen sind? Wenn man nämlich zwei Netzteile parallel schaltet und sie nicht immer ganz genau dieselbe Spannung liefern, dann kann es sein, dass sie sich gegenseitig totregeln.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 02 Oktober 2021, 19:01:22
Was mir aber aufgefallen ist: Es gibt ein Device 608F3FC4, welches ziemlich of Key-Events "an alle" schickt (4B an FFFFFF) und danach jedesmal eine Announce-Message (41 an FFFFFF). Ich kann mir nicht vorstellen, dass das so sein soll. Ich glaube, dass das Device nicht gepairt ist. Schau mal, ob das die Zentrale kennt.
Das ist ein HBW_SD6_MULTIKEY. Habe davon zwei Stück verbaut. Der andere ist 608F3FAC. Könnte man vergleichen. Deine Frage mit der Zentrale verstehe ich nicht. Das Device selbst ist in Fhem und einzelne Kanäle sind gepairt.
Hier mal ein Auszug aus dem List:
Internals:
DEF 608F3FC4
FUUID 5ed0e2c4-f33f-283d-9e61-1d7a47b69b806d5c
FVERSION 10_HM485.pm
FailedConfigReads 0
IODev HM485_LAN
NAME HBW_IO_12_1W_UP_v1_HBW0000708
NR 1097
RawDeviceType 178
RawFwVersion 578
STATE ACK
TYPE HM485
channel_01 EZ_6_fach_Taster_1
channel_02 EZ_6_fach_Taster_2
channel_03 EZ_6_fach_Taster_3
channel_04 EZ_6_fach_Taster_4
channel_05 EZ_6_fach_Taster_5
channel_06 EZ_6_fach_Taster_6
channel_07 EZ_BEW_Tisch
channel_08 HBW_IO_12_1W_UP_v1_HBW0000708_08
channel_09 HBW_IO_12_1W_UP_v1_HBW0000708_09
channel_10 HBW_IO_12_1W_UP_v1_HBW0000708_10
channel_11 HBW_IO_12_1W_UP_v1_HBW0000708_11
channel_12 HBW_IO_12_1W_UP_v1_HBW0000708_12
channel_13 EZ_6_fach_TasterLED_1
channel_14 EZ_6_fach_TasterLED_2
channel_15 EZ_6_fach_TasterLED_3
channel_16 EZ_6_fach_TasterLED_4
channel_17 EZ_6_fach_TasterLED_5
channel_18 EZ_6_fach_TasterLED_6
channel_19 EZ_6_fach_Taster_Hintergrundbeleuchtung
channel_20 HBW_IO_12_1W_UP_v1_HBW0000708_20
channel_21 HBW_IO_12_1W_UP_v1_HBW0000708_21
channel_22 HBW_IO_12_1W_UP_v1_HBW0000708_22
channel_23 HBW_IO_12_1W_UP_v1_HBW0000708_23
channel_24 HBW_IO_12_1W_UP_v1_HBW0000708_24
channel_31 HBW_IO_12_1W_UP_v1_HBW0000708_31
channel_32 HBW_IO_12_1W_UP_v1_HBW0000708_32
peer_act_0 channel_01 → EZ_Licht_Tisch
peer_act_1 channel_05 → Rol_EZ_SUED
peer_act_2 channel_06 → Rol_EZ_SUED
READINGS:
2021-09-27 20 D-deviceKey HBW_SD6_MULTIKEY
2021-09-27 20 D-fwVersion 2.66
2021-09-27 20 D-serialNr HBW0000708
2021-09-27 20 R-central_address 00000001
2021-09-27 20 R-logging_time 5.00
2021-09-27 20 R-own_address 1620000708
2021-09-27 20 configStatus OK
2021-09-27 20 state ACKZitat von: Thorsten Pferdekaemper am 02 Oktober 2021, 19:01:22
Könntest Du ansonsten mal genauer beschreiben, wie deine zwei Netzteile angeschlossen sind? Wenn man nämlich zwei Netzteile parallel schaltet und sie nicht immer ganz genau dieselbe Spannung liefern, dann kann es sein, dass sie sich gegenseitig totregeln.
Je Unterverteilung ein Netzteil das mit einem Buskabel verbunden ist. A, B und GND ist angeschlossen.
Hi,
dann frag mal beim Hersteller des HBW_SD6_MULTIKEY nach. Da stimmt meiner Meinung nach was nicht. Ein gepeertes Device sollte keine A-Meldungen schicken, außer vielleicht einmal beim Einschalten. Außerdem ist es etwas seltsam, dass es so viele 4B (Key Press) schickt. Das kann den Bus dann schon mal überlasten.
Zu den Netzteilen: Ich wollte nur sichergehen, dass die +24V nicht auch noch verbunden sind. (Ansonsten mache ich es genauso.)
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 03 Oktober 2021, 11:15:23
dann frag mal beim Hersteller des HBW_SD6_MULTIKEY nach. Da stimmt meiner Meinung nach was nicht. Ein gepeertes Device sollte keine A-Meldungen schicken, außer vielleicht einmal beim Einschalten. Außerdem ist es etwas seltsam, dass es so viele 4B (Key Press) schickt. Das kann den Bus dann schon mal überlasten.
OK, danke schon mal! Ich habe ihn mal angeschrieben und gefragt. Gibt es die Meldungen eigentlich auch von dem 608F3FAC? Das wäre der Baugleiche Aktor.
Hi,
ja, der 608F3FAC hat dasselbe Problem.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 03 Oktober 2021, 17:38:25
Hi,
ja, der 608F3FAC hat dasselbe Problem.
Gruß,
Thorsten
Danke dir. Der Hersteller hat auch schon geantwortet. Das sollte natürlich nicht so sein. Ich soll den Aktor nochmal neu anlernen, aber wenn beide Autoren die Meldung so oft senden, wird das wahrscheinlich nicht die Lösung sein, oder?
Hi,
das kann man nicht mit Sicherheit sagen, wenn man die Firmware nicht genau kennt. Einen Versuch ist es bestimmt Wert.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 03 Oktober 2021, 19:40:13
Hi,
das kann man nicht mit Sicherheit sagen, wenn man die Firmware nicht genau kennt. Einen Versuch ist es bestimmt Wert.
Gruß,
Thorsten
Ok, dann werde ich das einmal probieren. Nur um sicher zu gehen. Dazu Lösche ich die Device einfach in Fhem und lerne sie neu an, oder muss ich irgendwas noch beachten?