HBW-1W-T10 auf Arduino...

[joachimm]

Hallo,

wie ich bekomme das HEX File von kc-GitHub/HM485-Lib auf einen uno? Mit der Arduino ide ja nicht. Avrdude?

Danke
Joachim

[Thorsten Pferdekaemper]

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

[joachimm]

jepp, schönen Dank

[Thorsten Pferdekaemper]

...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

[loetmeister]

Hi,

ja.... ich hab mal angefangen HBW-1W-T10 auf die aktuelle Lib zu portieren... eigentlich nur als "Nebenprodukt". 
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

[Thorsten Pferdekaemper]

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.

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

[loetmeister]

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

[Thorsten Pferdekaemper]

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.

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 

[loetmeister]

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

[loetmeister]

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... 

Code Auswählen Erweitern

<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=4


Selbst als einfacher "integer" Wert klappt das setzen über "NOT_USED" nicht.... nur wenn der Wert "255" direkt eingegeben wird... 

Code Auswählen Erweitern

<parameter id="ONEWIRE_TYPE">
<logical type="integer" min="0" max="255">
<special_value id="NOT_USED" value="255"/>
...




Gruß,
Thomas

[loetmeister]

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? 

Code Auswählen Erweitern

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

[Thorsten Pferdekaemper]

Habe stattdessen mal den log level hochgestellt.... onewire_type wird nicht übersetzt. Liegts an meiner XML oder der HM485 FHEM lib? 

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

[Thorsten Pferdekaemper]

Hi,
hmmm... Das hier habe ich in ConfigurationManager.pm, sub convertSettingsToEepromData gefunden:

Code Auswählen Erweitern


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

[loetmeister]

Hi Thorsten,

super, danke. Wenn ich zum testen diesen Teil auskommentiere funktioniert es wie erwartet. 
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

[Thorsten Pferdekaemper]

super, danke. Wenn ich zum testen diesen Teil auskommentiere funktioniert es wie erwartet. 
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