OWX_ASYNC

Begonnen von Jewe, 15 August 2017, 09:27:48

Vorheriges Thema - Nächstes Thema

Jewe

Hallo,

was hat sich an dem Modul OWX_ASYNC geändert ? Ich hatte es in Betrieb, es hat gut funktioniert und ich war zufrieden damit.
Wie bekomme ich es wieder zum laufen ?

Kann ich notfalls auch wieder die "alte" version des Modules wieder installieren ?

https://forum.fhem.de/index.php/topic,74457.0.html

Jens

Jewe

#1
So, da ich nicht wirklich mit dem OWXServer / Device weiterkomme habe ich es nochmal mit dem "alten" aber funktionierendem OWX-Async probiert. Das klappte natürlich erstmal nicht.

Dann habe ich die Datei 21_OWTHERM.pm mit Datum 12.03.2017 ($Id: 21_OWTHERM.pm 13642 2017-03-08 16:41:55Z phenning $) auf dem Pi kopiert haben funktioniert es nun wieder.

An dieser Datei muss ja wohl was verändert worden sein, das den OWXAsync unbrauchbar macht.
Vielleicht liest das ja jemand der dazu mehr Ahnung hat als ich.

Jens

Erstmal gelöst, aber mit einem neuen Update wird es wohl wieder nicht mehr funktionieren.

Bartimaus

Moin,

wenn Du dem Device "global" das Attribut "exclude_from_update" mit der 21_OWTHERM.pm hinzufügst, kannst Du weiterhin Updates machen.
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Marlen

Guten Morgen,

ich hab auch massig solche Fehler in der LogFile

2017.08.17 06:54:17 1: OWXTHERM_BinValues:  Fuehler_Wz: invalid CRC,  22.8125  0x6d 0x01 0x4b 0x46 0x7f 0xff 0xff 0x7f 0x86
2017.08.17 06:57:18 1: OWX: Search CRC failed
2017.08.17 06:59:18 1: OWX: Search CRC failed
2017.08.17 07:00:18 1: OWX: Search CRC failed


Und meine Systemauslastung ist plötzlich angestiegen!

Allerdings wird die Temperatur noch ausgelesen!

LG
  Malren

Jewe

Zitat von: Bartimaus am 17 August 2017, 07:13:43
Moin,

wenn Du dem Device "global" das Attribut "exclude_from_update" mit der 21_OWTHERM.pm hinzufügst, kannst Du weiterhin Updates machen.
Super, Danke werde ich ausprobieren

Gesendet von meinem F5121 mit Tapatalk


Prof. Dr. Peter Henning

Zitatich hab auch massig solche Fehler in der LogFile

Da fehler leider jede Information. Welches Backend ? Welche Versionen ?

LG

pah

Marlen

21_OWTHERM.pm             14699 2017-07-13 08:07:17Z phenning
00_OWX.pm                 14108 2017-04-26 04:03:51Z phenning


Ich hab hier einfach an einen USB 1-Wire 2 Thermostate!

LG
  Marlen

Prof. Dr. Peter Henning

Diese Informationen passen vorne und hinten nicht zusammen. CRC-Fehler der neuen Frontendmodule können mit dem alten OWX gar nicht auftreten.

Für die beiden 1-Wire Thermometer wäre es das Einfachste, stattdessen gleich die Beta-Version von OWX Next Generation einzusetzen, ich hänge diese hier an.

LG

pah

Marlen

Danke pah,

ich versteh das nocht ganz, meine Temperaturfühler nutzen doch OWTHERM!?

LG
Marlen

Marlen

Ich bekomme die Fehler nicht weg!!!

2017.08.18 09:19:05 1: OWXTHERM_BinValues:  Fuehler_Wz: invalid CRC,  -0.0625  0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff

Bartimaus

Installier die alte Version von OWTHERM, anschliessend blockierst Du deren Update durch das Attribut im Device "global"
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Prof. Dr. Peter Henning

Wenn die Fehler nicht "wegzubekommen" sind, stimmt etwas mit den Sensoren oder der Verkabelung nicht. Wer die Fehlermeldungen nicht sehen will, muss eben verbose=0 setzen.

LG

pah

Marlen

ZitatInstallier die alte Version von OWTHERM, anschliessend blockierst Du deren Update durch das Attribut im Device "global"

Versuch ich heute Abend mal!!

ZitatWenn die Fehler nicht "wegzubekommen" sind, stimmt etwas mit den Sensoren oder der Verkabelung nicht. Wer die Fehlermeldungen nicht sehen will, muss eben verbose=0 setzen.

Ja, aber meine Systemauslastung ist auch hoch geschnallt, seit ich diesen Fehler habe, also geh ich davon aus, das dass zusammenhängt!

LG
  Marlen


Prof. Dr. Peter Henning

ZitatJa, aber meine Systemauslastung ist auch hoch geschnallt,
Noch einmal, hier passt etwas nicht zueinander. Bei Verwendung des neuen OWX Backends im synchronen Modus ergibt sich keinerlei Änderung gegenüber früher. Bei Verwendung im asynchronen Moduls sinkt die Systemlast nach übereinstimmenden Testberichten.

LG

pah

Marlen

Zitat von: Prof. Dr. Peter Henning am 18 August 2017, 12:03:19
Noch einmal, hier passt etwas nicht zueinander. Bei Verwendung des neuen OWX Backends im synchronen Modus ergibt sich keinerlei Änderung gegenüber früher. Bei Verwendung im asynchronen Moduls sinkt die Systemlast nach übereinstimmenden Testberichten.

Ja, das hast du schon geschrieben, aber ich versteh nicht wie das plötzlich kommt!
Es ging doch die ganze Zeit und plötzlich Fehlermeldungen und erhöhte Systemauslastung!

Was muss ich denn machen, dass es wieder zusammen passt!? Mein Device ist doch OWTherm, was hat das mit den OWX.....pm zu tun?

LG
  Marlen

Bartimaus

Mit OWTHERM wird der Sensor konfiguriert, mit OWX alternativ mit OWX_ASYNC der USB-Busmaster.

Hast Du letztens ein Update gemacht ? Wenn ja wurde damit OWTHERM aktualisiert, welches sich nicht soo dolle mit dem OWX_ASYNC verträgt.

Lt. dem Modulautor (pah) soll aber OWTHERM(neu) sich problemlos mit OWX(alt) vertragen. OWX neu ist IMO noch nicht im Update enthalten.

Darum: Spiele OWTHERM(alt) ein, mache einen Neustart, und berichte dann.
LG
B.


FHEM@Intel-J4105@Debian-LXC, CUL1101,FS20,IT,DS18B20,DS2413(Heizungslogger),DS2423(Stromlogger)Homematic,HM-LAN,ZWave,MiniCULs,Shelly

Beta-User

Oder nimm die neuen Module aus pah's Post (Next-Generation) dazu...
Dürfte die zukunftsweisendere Variante sein.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Marlen

Die hab ich schon!

Internals:
   ALARMED    1
   ASYNCHRONOUS 0
   DEF        /dev/ttyUSB1
   DeviceName /dev/ttyUSB1
   FD         54
   INITDONE   1
   INTERFACE  DS2480
   NAME       OWio1
   NEXT_OPEN  1502999863
   NR         358
   PARTIAL
   PRESENT    0
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   interval   300
   timeout    2
   version    7.0beta6
   DEVHASH:
     Fuehler_Wz 28.FFA7E8931605.CA
     OWio1      Busmaster
     WarmWasser 28.FF2AE1921604.8B
   DEVS:
     28.FF2AE1921604.8B
     28.FFA7E8931605.CA
   READINGS:
     2017-08-17 21:56:43   state           opened
Attributes:
   room       Fuehler
   verbose    3

Beta-User

Bin habe kein OWX mehr im Einsatz, aber m.E. sagt das list der OWX-Definition noch nichts über die Modul-Versionen, oder verstehe ich da was falsch?

https://fhem.de/commandref_DE.html#version
dürfte mehr helfen (und evtl. dazu führen, dass sich der Sache dann jemand annimmt, der aktuell diese Dinge nutzt) ;) ::) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Marlen

Latest Revision: 14712

File                      Rev   Last Change

fhem.pl                   14634 2017-07-03 08:33:25Z rudolfkoenig
39_alexa.pm               14128 2017-04-28 12:10:41Z justme1968
No Id found for 99_Alexa_Sprache_Utils.pm
96_allowed.pm             14681 2017-07-09 18:32:41Z rudolfkoenig
90_at.pm                  14519 2017-06-15 19:01:24Z rudolfkoenig
98_autocreate.pm          14530 2017-06-17 19:38:39Z rudolfkoenig
57_Calendar.pm            14494 2017-06-11 05:45:13Z neubert
57_CALVIEW.pm             14014 2017-04-17 15:02:28Z chris1284
98_cmdalias.pm            12935 2017-01-02 19:51:46Z rudolfkoenig
98_copy.pm                12200 2016-09-23 18:41:25Z justme1968
00_CUL.pm                 14119 2017-04-27 11:41:18Z rudolfkoenig
10_CUL_HM.pm              14626 2017-07-02 13:19:36Z martinp876
98_dummy.pm               12700 2016-12-02 16:49:42Z rudolfkoenig
34_ESPEasy.pm             14533 2017-06-18 06:46:35Z dev0
91_eventTypes.pm          11984 2016-08-19 12:47:50Z rudolfkoenig
00_FBAHA.pm               12235 2016-10-02 09:37:41Z rudolfkoenig
10_FBDECT.pm              13273 2017-01-29 17:35:45Z rudolfkoenig
72_FB_CALLMONITOR.pm      14142 2017-04-30 10:50:14Z markusbloch
No Id found for 96_FB_SIP.pm
01_FHEMWEB.pm             14677 2017-07-09 11:59:45Z rudolfkoenig
92_FileLog.pm             14206 2017-05-06 11:42:54Z rudolfkoenig
95_FLOORPLAN.pm           13735 2017-03-19 12:43:53Z UliM
72_FRITZBOX.pm            14623 2017-07-02 11:25:51Z tupol
98_Heating_Control.pm     13374 2017-02-09 20:00:35Z orti-otto
98_help.pm                13694 2017-03-13 19:24:13Z betateilchen
98_HourCounter.pm         11307 2016-04-25 08:02:06Z rudolfkoenig
98_HTTPMOD.pm             14231 2017-05-09 19:09:53Z StefanStrobel
49_IPCAM.pm                2626 2013-02-01 19:19:15Z mfr69bs
98_JsonList2.pm           13757 2017-03-20 19:17:02Z rudolfkoenig
32_mailcheck.pm           12339 2016-10-14 18:11:14Z justme1968
98_monitoring.pm          14549 2017-06-21 04:10:00Z igami
91_notify.pm              13630 2017-03-06 21:05:08Z rudolfkoenig
21_OWTHERM.pm             14699 2017-07-13 08:07:17Z phenning
# $Id: 00_OWX.pm 2016-11 pahenning $
# $Id: 11_OWX_SER.pm 2017-03 - pahenning $
73_PRESENCE.pm            14711 2017-07-13 20:31:11Z markusbloch
33_readingsGroup.pm       14044 2017-04-20 07:48:44Z justme1968
51_RPI_GPIO.pm            12129 2016-09-06 21:47:53Z klauswitt
91_sequence.pm            14216 2017-05-08 08:33:15Z rudolfkoenig
70_STV.pm                 12857 2016-12-21 11:59:33Z Zwiebel
99_SUNRISE_EL.pm          12485 2016-11-01 15:18:51Z rudolfkoenig
98_SVG.pm                 14655 2017-07-06 09:20:24Z rudolfkoenig
32_SYSSTAT.pm             10567 2016-01-18 21:34:09Z justme1968
50_TelegramBot.pm         14613 2017-07-01 10:18:33Z viegener
98_telnet.pm              14453 2017-06-02 17:37:59Z rudolfkoenig
59_Twilight.pm            14039 2017-04-19 19:59:56Z orti-otto
98_update.pm              14540 2017-06-19 09:02:19Z rudolfkoenig
99_Utils.pm               13259 2017-01-28 17:39:39Z rudolfkoenig
98_version.pm             13628 2017-03-06 20:43:50Z markusbloch
91_watchdog.pm            14337 2017-05-21 09:50:29Z rudolfkoenig
59_Weather.pm             12559 2016-11-13 08:54:54Z borisneubert
98_weblink.pm             13558 2017-03-01 09:42:51Z rudolfkoenig
98_WeekdayTimer.pm        13374 2017-02-09 20:00:35Z orti-otto
98_XmlList.pm             13128 2017-01-17 21:40:09Z rudolfkoenig

Blocking.pm               14677 2017-07-09 11:59:45Z rudolfkoenig
Color.pm                  11159 2016-03-30 16:08:06Z justme1968
DevIo.pm                  13865 2017-04-01 09:10:44Z rudolfkoenig
FritzBoxUtils.pm          14541 2017-06-19 09:13:10Z rudolfkoenig
HMConfig.pm               14631 2017-07-02 18:14:59Z martinp876
HttpUtils.pm              14654 2017-07-06 08:17:38Z rudolfkoenig
myUtilsTemplate.pm         7570 2015-01-14 18:31:44Z rudolfkoenig
myUtilsTemplate.pm         7570 2015-01-14 18:31:44Z rudolfkoenig
No Id found for ProtoThreads.pm
RTypes.pm                 10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm          12935 2017-01-02 19:51:46Z rudolfkoenig
TcpServerUtils.pm         14603 2017-06-30 09:38:41Z rudolfkoenig
YahooWeatherAPI.pm        12465 2016-10-29 09:01:31Z borisneubert

fhemweb.js                 14516 2017-06-15 11:01:57Z rudolfkoenig
fhemweb_colorpicker.js     13580 2017-03-02 13:03:29Z justme1968
fhemweb_fbcalllist.js      13629 2017-03-06 20:50:43Z markusbloch
fhemweb_readingsGroup.js   13580 2017-03-02 13:03:29Z justme1968
fhemweb_readingsHistory.js 13580 2017-03-02 13:03:29Z justme1968
fhemweb_sortable.js        13629 2017-03-06 20:50:43Z markusbloch
fhemweb_uzsu.js            13580 2017-03-02 13:03:29Z justme1968

Beta-User

Hmmm. Auch wenn man sich erst mal durchwursteln muß, sieht das eigentlich ok aus und kann eigentlich kaum mit einem update zusammenhängen, wenn Du das in letzter Zeit hin und wieder gemacht hast. (pah hätte vermutlich auch geholfen, wenn Du beide Infos (also das auf die OW....pm reduzierte Liste und das List von OWX) gleich geliefert hättest).

Und OWX_ASYNC hast Du ja gar nicht definiert, sondern OWX.

Das einzige, was mich etwas irritiert, ist das hier:
ZitatASYNCHRONOUS 0
Evtl. kannst Du mal versuchen, Async anzuschalten?


EDIT vor Abschicken:
Das Folgende hast Du intensiv geprüft?
Zitat von: Prof. Dr. Peter Henning am 18 August 2017, 10:08:22
Wenn die Fehler nicht "wegzubekommen" sind, stimmt etwas mit den Sensoren oder der Verkabelung nicht. Wer die Fehlermeldungen nicht sehen will, muss eben verbose=0 setzen.

LG

pah
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

Aus genau dem Grund gibt es nämlich in JEDEM OWXXX Modul ein Kommando get ... version.

LG

pah

Lucky2k12

Darf ich nochmal das hier einstreuen:
https://forum.fhem.de/index.php/topic,74457.msg672237.html#msg672237
scheint für mich dazu zu passen.
HP T610, HM, Jeelink, LGW, mapleCUL868+434

Marlen

Kann mal bitte jemand diese Datei hier rein hängen!

Zitat21_OWTHERM.pm mit Datum 12.03.2017 ($Id: 21_OWTHERM.pm 13642 2017-03-08 16:41:55Z phenning $)

LG
  Marlen

Marlen

So, hab jetzt erst nochmal ein FHEM-Update gemacht und dann die Dateien von pah rein kopiert und nach einen Neustart stand das im Log:
2017.08.18 20:33:00 1: OWX_Init called for bus OWio1 with interface state opened, now going for detect
2017.08.18 20:33:00 1: OWX_SER::Detect 1-Wire bus OWio1: interface master DS2480 re-detected
2017.08.18 20:33:00 1: ===============> OWX_Discover mit owx=OWX_SER=HASH(0x409f338)
2017.08.18 20:33:01 1: OWX_Discover: 1-Wire devices found on bus OWio1 (WarmWasser,Fuehler_Wz)


Und seit dem erst mal keine Fehlermeldungen!

Aber was bedeutet das:
2017.08.18 20:33:00 1: ===============> OWX_Discover mit owx=OWX_SER=HASH(0x409f338)

Allerdings ist  meine Systemauslastung immer noch recht hoch, was mir nicht gefällt!  >:(

LG
  Marlen

Beta-User

Wenn ich das jetzt richtig verstanden habe, hast Du jetzt OWX-NG drauf und die aktuellsten OW...-Module aus dem offiziellen FHEM-Bestand, oder?

Dann stell jetzt OWX doch mal auf async um (Vermutung: sollte per Attribut gehen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Marlen

O.k. hab auf async umgestellt:
Internals:
   ALARMED    no
   ASYNCHRONOUS 1
   BUSY       0
   DEF        /dev/ttyUSB1
   DeviceName /dev/ttyUSB1
   FD         53
   INITDONE   1
   INTERFACE  DS2480
   LASTSEND   1503085941.26205
   NAME       OWio1
   NR         358
   PARTIAL
   PRESENT    1
   ROM_ID     FF
   STATE      opened
   TYPE       OWX
   interval   600
   timeout    2
   version    7.0beta6
   DEVHASH:
     Fuehler_Wz 28.FFA7E8931605.CA
     OWio1      Busmaster
     WarmWasser 28.FF2AE1921604.8B
   DEVS:
     28.FF2AE1921604.8B
     28.FFA7E8931605.CA
   QUEUE:
   READINGS:
     2017-08-18 21:52:20   queue           1
     2017-08-18 21:28:30   state           opened
Attributes:
   asynchronous 1
   interval   600
   room       Fuehler
   verbose    3


Aber die Fühler kann ich  nicht umstellen!
Macht das was?
Was macht überhaupt async???

LG
  Marlen

Beta-User

1. Es funktioniert jetzt, oder? Und auch mit geringerer Systemlast, oder?

2. Mit Busmasern kenne ich mich nicht aus, aber ich versuchs mal:
Bei 1-wire hängt, wie der Name schon sagt, alles an einem Bus.
Man kann die Devices von Busmasterseite entweder direkt hart kontrollieren, was aber heißt, dass z.B. jeder Lesevorgang eines DS18B20 mit 12 Bit Auflösung (1/8Grad C) eine knappe Sekunde dauert, solange wartet der Master und tut nix anderes. Oder er stößt eben das Messen erst an und holt das Ergebnis später, muß dann aber verwalten, was alles abzuholen ist (und ggf. wann frühestens/spätestens), eben eine Queue, wie pah in dem anderen Beitrag schreibt.
Erfordert mehr Intelligenz, blockiert aber das System nicht. Wegen dieser Blockaden habe ich z.B. alles auf MySensors umgestellt. Wenn einer der Arduinos warten muß, stört mich das nicht, der sendet halt das Ergebnis, wenn er es hat, kann aber dafür auch nicht zu einem x-beliebigen Zeitpunkt abgefragt werden (jedenfalls nicht im Standard bei MySensors).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Marlen

Danke, für die Erklärung!
Ne, meine Systemlast is so zwischen 20% und 60%!

Beta-User

Systemlast bis 60% klingt nicht so toll.

Aktuell bei meiner TV-Box:
ZitatWelcome to ARMBIAN 5.27 stable Ubuntu 16.04.3 LTS 3.14.29   
System load:   0.08             Up time:       16 hours
Memory usage:  8 % of 1807Mb    IP:            192.168.2.59
CPU temp:      73°C           
Usage of /:    55% of 4.7G   

Hin und wieder schnellt für kurze Zeit einer der Kerne mal hoch, sehr gelegentlich mal sogar der zweite aber den größten Teil des Tages sind es eher 3% load (wobei das nicht unbedingt was mathematisch korrektes zu sagen hat, aber das war wieder eine andere Geschichte ;) ).

Und dass Kerne 3+4 je was zu tun hatten, wüßte ich nicht.
Evtl. mache ich morgen mal das Gehäuse weg und spendiere dem Teil einen Kühlkörper und ein Fritzbox-Gehäuse mit mehr Platz und Lüftungslöchern... 8)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Prof. Dr. Peter Henning

OWX_ASYNC stammt ebenso wir das 1-Wire Firmata Interface und des FHEM-Firmata Modul von Norbert Truchsess - der das aber seit einiger Zeit nicht mehr wartet oder weiter entwickelt. Sieht man u.a. daran, dass das allgemeine Firmata-Modul von FHEM die neueste Firmata-Version _eben nicht_ unterstützt.

Alles Nutzern von OWX_ASYNC sei geraten, vorerst beim alten Software-Stand zu bleiben und diese Module vom Update auszuschließen. ODER auf die oben gepostete OWX Next Generation umzustellen.
LG

pah

Marlen

So, ich hab jetzt noch einen aktiven USB-Switch vor meinen Busmaster gehängt......

Meine Systemauslastung is jetzt so um die 10% natürlich mit paar ausreisern!
Is zwar nicht wie zuvor, jedoch besser als 60%!

Mir bleibt der Fall allerdings ein Rätsel, da der Fehler ja einfach so aufgetreten ist! Ohne Update etc.

Ich hab 1-Wire mit 2 Temp.fühlern etwa seit März ohne Problem am laufen und wollte jetzt meine Fussbodenheizung damit steueren, die Hardware dazu hab ich schon da liegen.

Hmmm......

aber vielen lieben Dank für euere Hilfe!!  :-* :-* :-* :-*