@MichMein
Hallo Michael,
könnte mal wieder einen Tip von dir gebrauchen.
Hab vorgestern meinen Gaszähler nach Umbau neu gestartet und dabei hat er scheinbar statt 3120.xx dann 6120.xx gesehen. Dieser einmalig falsche Wert versaut mir nun meine Werte in Analytics. Manuell kann ich da scheinbar nix ändern.
Hast du ne Idee wo die Daten in Analytics gespeichert sind und wie man die wieder richtig stellen kann?
Beim Schraubenschlüssel habe ich den aktuellen Tageswert schon korrigiert. Wird aber in Current_Reading noch falsch angezeigt. Ev. muss ich ja bis morgen warten. Ob er dann auch Freitag korrigiert, keine Ahnung.

LG Horst

So jetzt hab ich es geschafft.
Nach freischalten von SPI mit Raspi-Config muss auch der IOBroker mit "sudo adduser iobroker spi" berechtigt werden.
Zum Auslesen habe ich folgenden Link genommen.
https://www.raspilc.de/Tutorials/4-Kanal-Analog-Modul-in-ioBroker-nutzen
Für den MPC3008 habe ich das Script entsprechend abgeändert.
Bus und Device stehen bei meinem Raspi-3 auf 0

</variables>
  <block type="procedures_defcustomnoreturn" id="+Mw]Y2?.93oBf(ge{jt~" x="113" y="63">
    <mutation statements="false">
      <arg name="busNumber" varid="K~~eKvUm{de`qR1Y:FLv"></arg>
      <arg name="deviceNumber" varid="H)HJx=.Wftan,x_J6wUF"></arg>
      <arg name="Interval" varid="T74|NyJod4GvB(.3RDC-"></arg>
    </mutation>
    <field name="NAME">Read_8AI_Modul</field>
    <field name="SCRIPT">Y3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWwwJywwLHJlYWQxKTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWwxJywwLHJlYWQyKTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWwyJywwLHJlYWQzKTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWwzJywwLHJlYWQ0KTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWw0JywwLHJlYWQ1KTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWw1JywwLHJlYWQ2KTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWw2JywwLHJlYWQ3KTsKY3JlYXRlU3RhdGUoJ0FuYWxvZ21vZHVsLkNoYW5uZWw3JywwLHJlYWQ4KTsKCmNvbnN0IG1jcGFkYyA9IHJlcXVpcmUoJ21jcC1zcGktYWRjJyk7CgoKCmZ1bmN0aW9uIHJlYWQxKCl7CmNvbnN0IGlucHV0MSA9IG1jcGFkYy5vcGVuTWNwMzAwOCgwLCB7YnVzTnVtYmVyOiBidXNOdW1iZXIsIGRldmljZU51bWJlcjpkZXZpY2VOdW1iZXIsICBzcGVlZEh6OiAyMDAwMH0sIChlcnIpID0+IHsKICBpZiAoZXJyKSB0aHJvdyBlcnI7CgogIHNldEludGVydmFsKCgpID0+IHsKICAgIGlucHV0MS5yZWFkKChlcnIsIHJlYWRpbmcpID0+IHsKICAgICAgaWYgKGVycikgdGhyb3cgZXJyOwoKICAgICAgc2V0U3RhdGUoIkFuYWxvZ21vZHVsLkNoYW5uZWwwIiwocmVhZGluZy5yYXdWYWx1ZSkpLHRydWU7CiAgICB9KTsKICB9LCBJbnRlcnZhbCk7Cn0pOwp9CgpmdW5jdGlvbiByZWFkMigpewpjb25zdCBpbnB1dDIgPSBtY3BhZGMub3Blbk1jcDMwMDgoMSwge2J1c051bWJlcjogYnVzTnVtYmVyLCBkZXZpY2VOdW1iZXI6ZGV2aWNlTnVtYmVyLCAgc3BlZWRIejogMjAwMDB9LCAoZXJyKSA9PiB7CiAgaWYgKGVycikgdGhyb3cgZXJyOwoKICBzZXRJbnRlcnZhbCgoKSA9PiB7CiAgICBpbnB1dDIucmVhZCgoZXJyLCByZWFkaW5nKSA9PiB7CiAgICAgIGlmIChlcnIpIHRocm93IGVycjsKCiAgICAgIHNldFN0YXRlKCJBbmFsb2dtb2R1bC5DaGFubmVsMSIsKHJlYWRpbmcucmF3VmFsdWUpKSx0cnVlOwogICAgfSk7CiAgfSwgSW50ZXJ2YWwpOwp9KTsKfQoKZnVuY3Rpb24gcmVhZDMoKXsKY29uc3QgaW5wdXQzID0gbWNwYWRjLm9wZW5NY3AzMDA4KDIsIHtidXNOdW1iZXI6IGJ1c051bWJlciwgZGV2aWNlTnVtYmVyOmRldmljZU51bWJlciwgIHNwZWVkSHo6IDIwMDAwfSwgKGVycikgPT4gewogIGlmIChlcnIpIHRocm93IGVycjsKCiAgc2V0SW50ZXJ2YWwoKCkgPT4gewogICAgaW5wdXQzLnJlYWQoKGVyciwgcmVhZGluZykgPT4gewogICAgICBpZiAoZXJyKSB0aHJvdyBlcnI7CgogICAgICBzZXRTdGF0ZSgiQW5hbG9nbW9kdWwuQ2hhbm5lbDIiLChyZWFkaW5nLnJhd1ZhbHVlKSksdHJ1ZTsKICAgIH0pOwogIH0sIEludGVydmFsKTsKfSk7Cn0KCmZ1bmN0aW9uIHJlYWQ0KCl7CmNvbnN0IGlucHV0NCA9IG1jcGFkYy5vcGVuTWNwMzAwOCgzLCB7YnVzTnVtYmVyOiBidXNOdW1iZXIsIGRldmljZU51bWJlcjpkZXZpY2VOdW1iZXIsICBzcGVlZEh6OiAyMDAwMH0sIChlcnIpID0+IHsKICBpZiAoZXJyKSB0aHJvdyBlcnI7CgogIHNldEludGVydmFsKCgpID0+IHsKICAgIGlucHV0NC5yZWFkKChlcnIsIHJlYWRpbmcpID0+IHsKICAgICAgaWYgKGVycikgdGhyb3cgZXJyOwoKICAgICAgc2V0U3RhdGUoIkFuYWxvZ21vZHVsLkNoYW5uZWwzIiwocmVhZGluZy5yYXdWYWx1ZSkpLHRydWU7CiAgICB9KTsKICB9LCBJbnRlcnZhbCk7Cn0pOwp9CgpmdW5jdGlvbiByZWFkNSgpewpjb25zdCBpbnB1dDUgPSBtY3BhZGMub3Blbk1jcDMwMDgoNCwge2J1c051bWJlcjogYnVzTnVtYmVyLCBkZXZpY2VOdW1iZXI6ZGV2aWNlTnVtYmVyLCAgc3BlZWRIejogMjAwMDB9LCAoZXJyKSA9PiB7CiAgaWYgKGVycikgdGhyb3cgZXJyOwoKICBzZXRJbnRlcnZhbCgoKSA9PiB7CiAgICBpbnB1dDUucmVhZCgoZXJyLCByZWFkaW5nKSA9PiB7CiAgICAgIGlmIChlcnIpIHRocm93IGVycjsKCiAgICAgIHNldFN0YXRlKCJBbmFsb2dtb2R1bC5DaGFubmVsNCIsKHJlYWRpbmcucmF3VmFsdWUpKSx0cnVlOwogICAgfSk7CiAgfSwgSW50ZXJ2YWwpOwp9KTsKfQoKZnVuY3Rpb24gcmVhZDYoKXsKY29uc3QgaW5wdXQ2ID0gbWNwYWRjLm9wZW5NY3AzMDA4KDUsIHtidXNOdW1iZXI6IGJ1c051bWJlciwgZGV2aWNlTnVtYmVyOmRldmljZU51bWJlciwgIHNwZWVkSHo6IDIwMDAwfSwgKGVycikgPT4gewogIGlmIChlcnIpIHRocm93IGVycjsKCiAgc2V0SW50ZXJ2YWwoKCkgPT4gewogICAgaW5wdXQ2LnJlYWQoKGVyciwgcmVhZGluZykgPT4gewogICAgICBpZiAoZXJyKSB0aHJvdyBlcnI7CgogICAgICBzZXRTdGF0ZSgiQW5hbG9nbW9kdWwuQ2hhbm5lbDUiLChyZWFkaW5nLnJhd1ZhbHVlKSksdHJ1ZTsKICAgIH0pOwogIH0sIEludGVydmFsKTsKfSk7Cn0KCmZ1bmN0aW9uIHJlYWQ3KCl7CmNvbnN0IGlucHV0NyA9IG1jcGFkYy5vcGVuTWNwMzAwOCg2LCB7YnVzTnVtYmVyOiBidXNOdW1iZXIsIGRldmljZU51bWJlcjpkZXZpY2VOdW1iZXIsICBzcGVlZEh6OiAyMDAwMH0sIChlcnIpID0+IHsKICBpZiAoZXJyKSB0aHJvdyBlcnI7CgogIHNldEludGVydmFsKCgpID0+IHsKICAgIGlucHV0Ny5yZWFkKChlcnIsIHJlYWRpbmcpID0+IHsKICAgICAgaWYgKGVycikgdGhyb3cgZXJyOwoKICAgICAgc2V0U3RhdGUoIkFuYWxvZ21vZHVsLkNoYW5uZWw2IiwocmVhZGluZy5yYXdWYWx1ZSkpLHRydWU7CiAgICB9KTsKICB9LCBJbnRlcnZhbCk7Cn0pOwp9CgpmdW5jdGlvbiByZWFkOCgpewpjb25zdCBpbnB1dDggPSBtY3BhZGMub3Blbk1jcDMwMDgoNywge2J1c051bWJlcjogYnVzTnVtYmVyLCBkZXZpY2VOdW1iZXI6ZGV2aWNlTnVtYmVyLCAgc3BlZWRIejogMjAwMDB9LCAoZXJyKSA9PiB7CiAgaWYgKGVycikgdGhyb3cgZXJyOwoKICBzZXRJbnRlcnZhbCgoKSA9PiB7CiAgICBpbnB1dDgucmVhZCgoZXJyLCByZWFkaW5nKSA9PiB7CiAgICAgIGlmIChlcnIpIHRocm93IGVycjsKCiAgICAgIHNldFN0YXRlKCJBbmFsb2dtb2R1bC5DaGFubmVsNyIsKHJlYWRpbmcucmF3VmFsdWUpKSx0cnVlOwogICAgfSk7CiAgfSwgSW50ZXJ2YWwpOwp9KTsKfQo=</field>
    <comment pinned="false" h="80" w="160">Liest die Werte des 4-Kanal-Analogmoduls.busNumber &gt; Nr. des SPI-Busses (RasPi 1= 0, RasPi2/3=1, Tinker Board=2deviceNumber &gt; genutzte CS-Leitung (0 oder1)    </comment>
  </block>
  <block type="procedures_callcustomnoreturn" id="-vA)=,47jm|xOTu0RiVL" x="113" y="113">
    <mutation name="Read_8AI_Modul">
      <arg name="busNumber"></arg>
      <arg name="deviceNumber"></arg>
      <arg name="Interval"></arg>
    </mutation>
    <value name="ARG0">
      <block type="math_number" id="WyP!BzAW=l|c9CGnp16C">
        <field name="NUM">0</field>
      </block>
    </value>
    <value name="ARG1">
      <block type="math_number" id="5T0mmPWZx62Y}FGh,:b]">
        <field name="NUM">0</field>
      </block>
    </value>
    <value name="ARG2">
      <block type="math_number" id="`aS~(w8[IA,QtW-P+0V7">
        <field name="NUM">10000</field>
      </block>
    </value>
  </block>
</xml>_text

@Garfonso

Hallo Garfonso,
ich habe gerade das Update mit der Katze auf 2.3.2 aufgespielt.
Es kam eine Meldung, dass ich

sudo apt --fix-broken install

auführen soll was ich auch gemacht habe. Beim zweiten Update kam dann eine Ellenlange liste

sudo apt --fix-broken install

$ iobroker url iobroker-community-adapters/ioBroker.rpi2 --host raspberrypi --debug
install iobroker-community-adapters/ioBroker.rpi2
NPM version: 10.8.2
Installing iobroker-community-adapters/ioBroker.rpi2... (System call)
> iobroker.rpi2@2.3.2 preinstall> sudo apt-get install -y libgpiod-dev || exit 0
Reading package lists...
Building dependency tree...
Reading state information...
libgpiod-dev is already the newest version (1.6.3-1+b3).The following package was automatically installed and is no longer required:
libcamera0.3Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> node-dht-sensor@0.4.4 install> node-gyp configure
gyp info it worked if it ends with okgyp info using node-gyp@10.1.0gyp info using node@20.18.2 | linux | arm64
gyp info find Python using Python version 3.11.2 found at "/usr/bin/python3"
gyp info spawn /usr/bin/python3
gyp info spawn args [
gyp info spawn args '/usr/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',gyp info spawn args 'binding.gyp',gyp info spawn args '-f',gyp info spawn args 'make',gyp info spawn args '-I',gyp info spawn args '/opt/iobroker/node_modules/node-dht-sensor/build/config.gypi',gyp info spawn args '-I',gyp info spawn args '/usr/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',gyp info spawn args '-I',gyp info spawn args '/home/iobroker/.cache/node-gyp/20.18.2/include/node/common.gypi',gyp info spawn args '-Dlibrary=shared_library',gyp info spawn args '-Dvisibility=default',gyp info spawn args '-Dnode_root_dir=/home/iobroker/.cache/node-gyp/20.18.2',gyp info spawn args '-Dnode_gyp_dir=/usr/lib/node_modules/npm/node_modules/node-gyp',gyp info spawn args '-Dnode_lib_file=/home/iobroker/.cache/node-gyp/20.18.2/<(target_arch)/node.lib',gyp info spawn args '-Dmodule_root_dir=/opt/iobroker/node_modules/node-dht-sensor',gyp info spawn args '-Dnode_engine=v8',gyp info spawn args '--depth=.',gyp info spawn args '--no-parallel',gyp info spawn args '--generator-output',gyp info spawn args 'build',gyp info spawn args '-Goutput_dir=.'gyp info spawn args ]
gyp info ok 
> opengpio@1.0.17 install> node-gyp rebuild
gyp info using node-gyp@10.1.0gyp info using node@20.18.2 | linux | arm64
gyp info find Python using Python version 3.11.2 found at "/usr/bin/python3"
gyp info spawn /usr/bin/python3
gyp info spawn args '-I',gyp info spawn args '/opt/iobroker/node_modules/opengpio/build/config.gypi',gyp info spawn args '-I',gyp info spawn args '/usr/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',gyp info spawn args '-I',gyp info spawn args '/home/iobroker/.cache/node-gyp/20.18.2/include/node/common.gypi',gyp info spawn args '-Dlibrary=shared_library',gyp info spawn args '-Dvisibility=default',gyp info spawn args '-Dnode_root_dir=/home/iobroker/.cache/node-gyp/20.18.2',gyp info spawn args '-Dnode_gyp_dir=/usr/lib/node_modules/npm/node_modules/node-gyp',gyp info spawn args '-Dnode_lib_file=/home/iobroker/.cache/node-gyp/20.18.2/<(target_arch)/node.lib',gyp info spawn args '-Dmodule_root_dir=/opt/iobroker/node_modules/opengpio',gyp info spawn args '-Dnode_engine=v8',gyp info spawn args '--depth=.',gyp info spawn args '--no-parallel',gyp info spawn args '--generator-output',gyp info spawn args 'build',gyp info spawn args '-Goutput_dir=.'gyp info spawn args ]
gyp info spawn makegyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
CXX(target) Release/obj.target/opengpio/cpp/opengpio.o
SOLINK_MODULE(target) Release/obj.target/opengpio.node
COPY Release/opengpio.node
make: Leaving directory '/opt/iobroker/node_modules/opengpio/build'
gyp info ok 
> node-dht-sensor@0.4.4 postinstall> node-gyp build
gyp info using node-gyp@10.1.0gyp info using node@20.18.2 | linux | arm64
gyp info spawn make
CC(target) Release/obj.target/nothing/node_modules/node-addon-api/src/nothing.o
rm -f Release/obj.target/node_modules/node-addon-api/src/nothing.a Release/obj.target/node_modules/node-addon-api/src/nothing.a.ar-file-list; mkdir -p `dirname Release/obj.target/node_modules/node-addon-api/src/nothing.a`
ar crs Release/obj.target/node_modules/node-addon-api/src/nothing.a @Release/obj.target/node_modules/node-addon-api/src/nothing.a.ar-file-list
CC(target) Release/obj.target/node_dht_sensor/src/bcm2835/bcm2835.o
../src/bcm2835/bcm2835.c: In function ‘bcm2835_init’:
../src/bcm2835/bcm2835.c:1818:84: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 1818 | bcm2835_peripherals = mapmem("gpio", bcm2835_peripherals_size, memfd, (off_t)(uint32_t)bcm2835_peripherals_base); | ^../src/bcm2835/bcm2835.c:1851:84: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 1851 | bcm2835_peripherals = mapmem("gpio", bcm2835_peripherals_size, memfd, (off_t)(uint32_t)bcm2835_peripherals_base); | ^
CXX(target) Release/obj.target/node_dht_sensor/src/node-dht-sensor.o
CXX(target) Release/obj.target/node_dht_sensor/src/dht-sensor.o
CXX(target) Release/obj.target/node_dht_sensor/src/util.o
SOLINK_MODULE(target) Release/obj.target/node_dht_sensor.node
COPY Release/node_dht_sensor.node
make: Leaving directory '/opt/iobroker/node_modules/node-dht-sensor/build'
gyp info ok 
added 7 packages in 1m155 packages are looking for funding run `npm fund` for details
upload [13] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/de/translations.json i18n/de/translations.json application/json
upload [12] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/en/translations.json i18n/en/translations.json application/json
upload [11] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/es/translations.json i18n/es/translations.json application/json
upload [9] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/it/translations.json i18n/it/translations.json application/json
upload [8] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/nl/translations.json i18n/nl/translations.json application/json
upload [7] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/pl/translations.json i18n/pl/translations.json application/json
upload [6] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/pt/translations.json i18n/pt/translations.json application/json
upload [5] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/ru/translations.json i18n/ru/translations.json application/json
upload [3] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/i18n/zh-cn/translations.json i18n/zh-cn/translations.json application/json
upload [1] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/rpi2.png rpi2.png image/png
upload [0] rpi2.admin /opt/iobroker/node_modules/iobroker.rpi2/admin/words.js words.js application/javascript
Updating objects from io-package.json for adapter "rpi2" with version "2.3.2"
Process exited with code 0

Die Ausgänge hab ich auf Ausgangsstellung 0 eingestellt.
Der Adapter schaltet jetzt ganz kurz alle Relais was auch wahrscheinlich früher so war und zeigt den Zustand dann auch richtig an. Ich wäre aus jetzigen Stand damit zufrieden. Werde morgen mal testen wie er sich bei Ausgangsstellung 1 oder nur Ausgang verhält und es dir melden.
Vielen, vielen Dank schon mal.
LG Horst

PS: Mit meinem Update auf Bookworm wäre ich dann nach 4 Tagen (40Stunden) bis auf den SPI durch.
SPI brauch ich für meine Feuchtigkeitsfühler. Am leichtesten war das IoBroker Update. Am längsten hat der eBus gedauert.
Hab jetzt alles Dokumentiert;-). Ist jetzt nur noch SPI offen dann hab ichs geschafft.
Edit9.02.2025 > Bin leider noch nicht zum Testen von Input, Anfang1 und Ausgang gekommen mach das aber noch!!!
Komme abar mit SPI grad leider überhaupt nicht weiter, unter bookworm und 64bit hat sich alles geändert. Wenn jemand weiß wie ich da weiter komme wäre ich für jede Hilfe dankbar. Auch wiringpi gibt es scheinbar nicht mehr.
Hab neuen Thread "MCP3008 in IoBroker einbinden" angelegt.

@jomjol sagte in Wasserzähler - Version 2 - all-in-device:

@Hasont Da fehlt irgendwo im Code noch eine korrektes Runden - ich mache mal selbst ein Issue und bei nächster Gelegenheit suche ich nach dem Bug

Hallo, hab die neue Version gerade aufgespielt und jetzt wird alles auch nach der Kommastelle richtig angezeigt!
Vielen Dank

PS: Wegen meines Wunsches ev. auch einen GPIO anzusteuern damit man über ein Relais auch bei Bedarf das Wasser abstellen könnte hab ich jetzt erstmal durch eine gesonderter Kabelverlegung realisiert.

LG Horst

@rene_hm
Vielen vielen Dank, hab über github die v3.3.8 installiert und danach Upload von Vis gemacht. War sofort wieder in aller schönheit da.

LG Horst

@Garfonso

Hallo Garfonso,

die 2.3.2 habe ich nun an meinen 8 Ausgängen und 6 Eingängen getestet und bin für meine Anwendungen mit Ausgang, Ausgangswert 0 absolut zufrieden. Beim Hochfahren werden kurz alle Relais ein- und ausgeschaltet und damit kann ich leben. Die Anzeige in den Objekten ist danach korrekt.

Dann habe ich alle Ausgang, Ausgangswert 1 eingestellt. Rpi2 startet neu und alle Relais sind eingeschaltet.
Auch hier ist die Anzeige in den Objekten und der VIS korrekt.

Ich habe dann alle auf Ausgang, Ausgang gestellt und 4 Relais ein und 4 ausgeschaltet.
Nach Neustart von Rpi2 wurden diese in den Objekten und in VIS richtig angezeigt.
Allerdings war es so, dass alle Relais angezogen haben. Die im Objekt eingeschalteten Relais konnte über VIS sofort ausgeschaltet werden. Die als "aus" angezeigten Ausgänge waren ein und mussten über die VIS erst ein- (nix passiert) und dann ausgeschaltet werden. Dann passt wieder alles.

Die Eingänge habe ich mit 200ms entprellt. Ab und zu reagieren diese noch immer beim Einschalten von induktiven Lasten in unmittelbarer Nähe wie z.B. Trafo für die Gartenventile und Leuchtstoffröhre. Ist aber für meine Anwendung "3min Wasser vorm Haus nach Tastendruck" nicht problematisch.
Gibt es für die Eingänge schon Werte die man als Standard annehmen kann. Ich konnte mit 100ms und 200ms noch keine Unterschiede feststellen. Habe auch in meinen Script noch entprellt.

Vielen Dank nochmal für die schnelle Bereitstellung der 2.3.2.

LG Horst

@mierscheid
Mein Kugelventil im Thread 804 mit dem Relais in Tread 808 hat den Vorteil, dass es nur Strom verbraucht wenn es öffnet oder schließt. Ich denke auch, dass man bei einem Wasserschaden auch nach 4,87 min das gröbste verhindert und daher wäre das besser als nichts und Wasser ganz aus im Urlaub würde mein Garten gar nicht gut finden;-). Bin grad dabei den Wasserstop während des Gießens dann auszusetzen indem ich den Urlaubsmodus für diese Zeit sperre. Blöd dabei ist, dass ich wegen Überschneidung der Auslesezeit und Meldung des Zählers mindestens zwei Runden aussetzen muss. Deine Idee auch Übertragungsfehler mit zu berücksichtigen ist auch noch eine Überlegung Wert. Mein Raspi hängt z.B. an einer FritzDect Steckdose damit man hier auch mal einen Reset machen könnte sofern die Fritzbox noch läuft.

@hasont sagte in Test Adapter rpi2 2.x:

@Garfonso

Hallo Garfonso,

die 2.3.2 habe ich nun an meinen 8 Ausgängen und 6 Eingängen getestet und bin für meine Anwendungen mit Ausgang, Ausgangswert 0 absolut zufrieden. Beim Hochfahren werden kurz alle Relais ein- und ausgeschaltet und damit kann ich leben. Die Anzeige in den Objekten ist danach korrekt.

@Garfonso @Smallfeuer

Zur Info, ich bin noch immer auf der von Garfonso vorgeschlagenen 2.3.2 vom 9.02.2025.
Wie damals von mir bemerkt sollte bei der Weiterentwicklung ev. auch das Startverhalten vom Adapter bei den Ausgängen mal angesehen werden. Nach Reboot des Raspie und/oder der rpi2 Instanz werden immer alle Ausgänge für ne ms False/True/False gesetzt. Für mich nicht problematisch. Wenn da aber z.B. ein Garagentor mit Taster dran wäre dann ginge das auf. Warum die Relais hier kurz toggeln und ob das nur in der 2.3.2 ist weiß ich nicht.
In der damaligen 2.3.1 wurden ja alle Relais nach dem Start dauerhaft auf True gesetzt was aber ja nicht richtig sein kann.

@bruchpilot
So, hab grad mit SDCardFormater die SD Karte neu formatiert

Danach die Daten im Original aufgespielt und mit Note++ die WLAN Daten eingegeben.
Die Daten hab ich nun nicht mit USB-Adapter sondern mit einem SD-Adapter aufgespielt.

Was soll ich sagen, beide laufen jetzt;-)
Viel Glück!!!!!!!

Nachtrag 19.03.2020: Von 8 4GB Karten laufen 4 (Transcent) die anderen (SanDisk) gehen nicht.
Alle auf die selbe teils mehrfach partitioniert. Bei fehlender SD blinkt am ESP32-Cam nichts.
Hab die neueste Software aus dem Rolling benutzt.

@dock07 sagte in Test Adapter rpi2 2.x:

@garfonso >Bei nur "Ausgang" macht der Adapter beim start gar nichts|<

Kann ich so nicht bestätigen. In dem Moment beglückt mich der GPIO beim Start mit einem unerwünschten "true", eigentlich genau so wie bei eingestelltem Anfangswert 1

mit Ausgang Anfangswert 0 kommt es bei mir, und wahrscheinlich z.B. auch bei @Hasont, zu dem ungewünschten false true false bei Neustart.

Ohne die Initialisierung des jeweiligen GPIO durch den Adapter bleibt dieser auf null/ false, also so wie von mir gewünscht.

@Garfonso
@dock07
Hallo, also bei mir in der 2.3.2 ist es genau so wie bei dock07.
Wie bereits weiter oben schon mal geschrieben sind mir folgende Dinge aufgefallen:
1.) Startverhalten mit false/true/false bei Ausgang = 0
2.) Wenn ich den rpi2 Prozess pausiere und den Raspie neu reboote bleibt alles false wie es sein soll!
Starte ich den rpi2 Prozess wieder gehen alle Relaise auf true/false.
3.) Wenn ich bei Ausgang = Ausgang 4 GPIOs der Relais 1-4 auf true stelle und 4 GPIOs der Relaise 5 - 8 auf false und dann die Instanz rpi2 neu starte werden erstmal alle Ausgänge auf true gesetzt und die GPIOs der Relais 1 - 4 bleiben true und die GPIOs der Relais 5 - 8 gehen true/false. Die GPIOs der Relais 5 - 8 werden somit auch erstmal falsch auf true gesetzt.
Meine Relaise sind true wenn an den GPIOs 3,3V anliegen. So ist es Standard beim Raspie.

Bei den Eingängen ist es bei mir tatsächlich so, dass ein mit 3,3V dauerhaft auf true gesetzter Eingang manchmal für eine ganze Zeit lang nach Reboot vom Raspie oder der rpi2 Instanz als false im Objekt ansteht. Das ändert sich komischerweise erst wenn irgendein Trigger anliegt. Ich hab das bisher nur in den Objekten beobachtet. Trigger kann eine geschaltete Neonröhre oder ein Login über die App sein.
Ev. könnte ich da ja mal den Status mit pinctrl im Raspi selbst abfragen.

Ich kann das leider nur schlecht beschreiben da es nicht sauber nachvollziehbar ist.

Hallo, nachdem ich leider noch immer Fehlermeldungen an den Inputs bekomme (Ohne Tastendruck wird dieser immer wieder mal trotzdem erkannt) hab ich alle meine 6 Inputs (GPIO 17, 18, 22, 23, 24 und 27) nochmal abgeklemmt und so getestet. Beim messen der unbelegten Eingänge fällt auf, dass 18, 22, 24 und 27 gegen 3,3V richtig die 3,3V anzeigen. GPIO 17 und GPIO 23 aber 1,7V.
Ich verwende derzeit nur GPIO 23. Bei der Abfrage über raspi-gpio get werden die Eingänge auch als Input angezeigt (siehe Kopie der Ausgabe) Der Taster wird mit 3,3V vom Raspi gespeist und liegt 10m entfernt.
In der RPI2 Instanz hab ich derzeit 500ms Entprellen eingestellt da bei 100ms noch mehr Fehler vorkamen.
Der Input 24 und 27 werden bei 3,3V gar nicht erkannt und bei 24 geht 23 mit (alles ohne was angeschlossen zu haben). Die Eingänge 17 und 23 sind auch extrem empfindlich. Da reicht schon das Messen mit dem Vielfach aus um die zu aktivieren.

Ich probiere jetzt mal folgendes: Taster an GPIO 18 und 22 und dann schalte ich mein Relais erst wenn beide Eingänge erkannt werden und Berichte was dabei raus kam.

Ev. hat ja jemand eine Idee wo der Fehler noch sein könnte. Insbesonder warum die Eingänge 17 und 23 bei 10k gegen Masse 1,7 V haben gegenüber den anderen 4 Eingängen die sauber auf Masse liegen.
Meine weiteren Threads zum Thema sind auf Seite 433,435,468,476,479,484,493,495 und 509 zu finden.

pi@raspberrypi:/sys/class/gpio $ raspi-gpio get
BANK0 (GPIO 0 to 27):
GPIO 0: level=1 func=INPUT pull=UP
GPIO 1: level=1 func=INPUT pull=UP
GPIO 2: level=1 alt=0 func=SDA1 pull=UP
GPIO 3: level=1 alt=0 func=SCL1 pull=UP
GPIO 4: level=1 func=INPUT pull=UP
GPIO 5: level=1 func=INPUT pull=UP
GPIO 6: level=1 func=INPUT pull=UP
GPIO 7: level=1 func=OUTPUT pull=UP
GPIO 8: level=1 func=OUTPUT pull=UP
GPIO 9: level=0 alt=0 func=SPI0_MISO pull=DOWN
GPIO 10: level=0 alt=0 func=SPI0_MOSI pull=DOWN
GPIO 11: level=0 alt=0 func=SPI0_SCLK pull=DOWN
GPIO 12: level=0 func=OUTPUT pull=DOWN
GPIO 13: level=0 func=OUTPUT pull=DOWN
GPIO 14: level=1 alt=5 func=TXD1 pull=NONE
GPIO 15: level=1 alt=5 func=RXD1 pull=UP
GPIO 16: level=0 func=OUTPUT pull=DOWN
GPIO 17: level=0 func=INPUT pull=DOWN
GPIO 18: level=0 func=INPUT pull=DOWN
GPIO 19: level=0 func=OUTPUT pull=DOWN
GPIO 20: level=0 func=OUTPUT pull=DOWN
GPIO 21: level=0 func=OUTPUT pull=DOWN
GPIO 22: level=0 func=INPUT pull=DOWN
GPIO 23: level=0 func=INPUT pull=DOWN
GPIO 24: level=0 func=INPUT pull=DOWN
GPIO 25: level=0 func=OUTPUT pull=DOWN
GPIO 26: level=0 func=OUTPUT pull=DOWN
GPIO 27: level=0 func=INPUT pull=DOWN
code_text

Edit 5.08 Hab jetzt GPIO 18 genommen und es ist seit 7 Tage Ruhe.
Irgendwas stimmt mit 17 und 23 scheinbar nicht was ja auch der Pegel von 1,7V in Ruhe zeigt. Ev. hat ja einer hier noch eine Idee wie man das ev. mit einem Befehl im Editor zurechtbiegen könnte.

Würde mich über eine Antwort freuen.

@hasont
Kurz gesagt es war der Cron.
Der stand auf einer Minute und ich hab Ihn auf zwei gestellt. Fehler ist weg, mein Dauerfehler den ich im Log weggeschaltet hatte ist aber immer noch da. Falls hier noch jemand einen Tip hat!!!!!

host.raspberrypi
	2025-07-19 16:20:00.022	warn	instance system.adapter.ebus.0 already running with pid 17860
host.raspberrypi
	2025-07-19 16:18:00.024	warn	instance system.adapter.ebus.0 already running with pid 17860

@rene_hm

Hallo, ich habe heute gesehen, dass es seit 11.07 17:35 keine Updates mehr in meinen Ebus Objekten gibt.

Raspi Update und Upgrade habe ich schon gemacht aber nach Neustart der IoBroker Instanz kommt im Log immer
"system.adapter.ebus.0 schedule attribute missing"
Auch das EBUS Update auf 3.6.2 hat keine Verbesserung gebracht.

Habt Ihr ne Idee wo ich da ansetzen könnte oder muss ich den EBUS neu aufsetzen?

@meintre-0

Der Befehl

ebusctl write -c 470 HwcOPMode "manual"

geht nicht?
Als Status steht oben doch "470 HwcOPMode = off"
Also kann er den aktuellen Status ja auch auslesen!
Wichtig ist, dass du den Wert in "manual" "auto" oder "off" in " " eingibst.

@meintre-0

Hallo, ich hab mir dafür Scripts gebaut die man dann auch im VIS als Objekte bedienen kann.
Hier mal die VIS als Bild

und meine Scripts dazu.

createState('javascript.0.Heizung.Warmwasserschalter', {type: 'string',def: 1});
on('javascript.0.Heizung.Warmwasserschalter', function (obj) {

  if (obj.state.val == "manual"){

        log("Wert wurde auf manual gesetzt", 'info');

        exec('ebusctl write -c 430 HwcOPMode "manual"');

     }

     else if (obj.state.val == "off"){

         log("Wert wurde auf off gesetzt", 'info');

         exec('ebusctl write -c 430 HwcOPMode "off"');

     }

     else if (obj.state.val == "auto"){

         log("Wert wurde auf auto gesetzt", 'info');

         exec('ebusctl write -c 430 HwcOPMode "auto"');

     }
     
});

createState('javascript.0.Heizung.Innentemperatur man', {type: 'number',def: 1});
on('javascript.0.Heizung.Innentemperatur man', function (obj) {

  if (obj.state.val == "20"){

        log("Wert wurde auf 20 Grad gesetzt", 'info');

        exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 20');

     }

     else if (obj.state.val == "20.5"){

         log("Wert wurde auf 20,5 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 20.5');

     }

     else if (obj.state.val == "21,0"){

         log("Wert wurde auf 21 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 21');

     }
     
     else if (obj.state.val == "21.5"){

         log("Wert wurde auf 21,5 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 21.5');

     }

     else if (obj.state.val == "22"){

         log("Wert wurde auf 22 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 22');

     }

        else if (obj.state.val == "22.5"){

         log("Wert wurde auf 22,5 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 22.5');

     }

     else if (obj.state.val == "23"){

         log("Wert wurde auf 23 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 23');

    
     }
     
     else if (obj.state.val == "23.5"){

         log("Wert wurde auf 23,5 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 23.5');

     }

     else if (obj.state.val == "24"){

         log("Wert wurde auf 24 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 24');

 }
     
     else if (obj.state.val == "24.5"){

         log("Wert wurde auf 24,5 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 24.5');

     }

     else if (obj.state.val == "25"){

         log("Wert wurde auf 25 Grad gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1ManualOPRoomTempDesired 25');
     
     }
});

createState('javascript.0.Heizung.Heizungsmodus', {type: 'number',def: 1});
on('javascript.0.Heizung.Heizungsmodus', function (obj) {

  if (obj.state.val == "0"){

        log("Wert wurde auf off gesetzt", 'info');

        exec('ebusctl write -c 430 Hc1RoomTempSwitchOn "0"');

     }

     else if (obj.state.val == "1"){

         log("Wert wurde auf modulating gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1RoomTempSwitchOn "1"');

     }

     else if (obj.state.val == "2"){

         log("Wert wurde auf thermostat gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1RoomTempSwitchOn "2"');

     }
     
});

createState('javascript.0.Heizung.Heizungsschalter', {type: 'string',def: 1});
on('javascript.0.Heizung.Heizungsschalter', function (obj) {

  if (obj.state.val == "manual"){

        log("Wert wurde auf manual gesetzt", 'info');

        exec('ebusctl write -c 430 Hc1OPMode "manual"');

     }

     else if (obj.state.val == "off"){

         log("Wert wurde auf off gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1OPMode "off"');

     }

     else if (obj.state.val == "auto"){

         log("Wert wurde auf auto gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1OPMode "auto"');

     }
     
});

createState('javascript.0.Heizung.Heizungsmodus', {type: 'number',def: 1});
on('javascript.0.Heizung.Heizungsmodus', function (obj) {

  if (obj.state.val == "0"){

        log("Wert wurde auf off gesetzt", 'info');

        exec('ebusctl write -c 430 Hc1RoomTempSwitchOn "0"');

     }

     else if (obj.state.val == "1"){

         log("Wert wurde auf modulating gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1RoomTempSwitchOn "1"');

     }

     else if (obj.state.val == "2"){

         log("Wert wurde auf thermostat gesetzt", 'info');

         exec('ebusctl write -c 430 Hc1RoomTempSwitchOn "2"');

     }
     
});

@smallfeuer
hallo die Fehlermeldung oben kommt bei mir auch wenn ich RPI2 Instanz aufrufe, auch ohne Änderung. Hab ich schon öffter mal gefragt und ignoriere das halt jetzt. Zum Thema mit den Eingängen hab ich lange probiert und auch immer wieder geschrieben, dass es diesen sporatischen Wechsel (bei mir manchmal auch mehrfach am Tag) gibt. Entprellen erhöht und kleinere Widerstände am Eingang mit Kondensator alles schon probiert aber alles ohne Erfolg. Schaltung seit 4 Jahren gleich. Der Eingang steuert meine Giesanlage vorm Haus für die Nachbarn. Damit gebe ich dann 3min Wasser frei. Ist nicht schlimm solange der Schlauch dicht ist. Ich bekomme über Telegram dann Hauswasser vorne ein gemeldet. Ich dachte anfangs auch, dass das nur bei Neonlicht ein, Wasserventile ein oder Heizung ein passiert. Ist da auch sehr häufig zu beobachten. Nachts um 2:00 passiert da aber definitiv nichts und auch da hatte ich schon diese Art von meldungen. Entprellung steht mittlerweile auf 1000ms und trotzdem ist das so. Auch beim hochfahren vom Raspie wird ein vorher fest auf High gelegter Kontakt nur sporatisch erkannt. Ich kann mich nur widerholen und würde hier keinesfalls RPI2 für Torsteuerungen oder sowas verwenden. Ich baue grad mit ESP32 und Tasmota eine Torsteuerung da meine Einhell kaputt gegangen ist. Alle meine ESP32 Projekte laufen seit Jahren problemlos. Wenn hier keine Verbesserung mehr kommt nutze ich den Raspie nur noch zur Virtuellen Steuerung.

@azrael42
Hallo, ich bin zwar nicht kanumouse aber ich hab das Problem auch schon seit über einem Jahr. Dachte mal es wäre weg wenn man den Adapter über das Terminal beendet und wieder startet aber leider kann ich das so nicht mehr nachvollziehen. Im ebus wird ja lt. Beschreibung der Bus mit dem Befehl "Make the daemon autostart with sudo systemctl enable ebusd" beim Starten vom Raspie automatisch gestartet.
Ev. passiert das gleiche nochmal beim Start vom IoBroker und der Dienst läuft dann zweimal.
Vieleicht meldet sich ja diesmal jemand der uns da helfen kann. Habs leider nicht weiter verfolgt. Nach Update auf Bookworm ist das immer noch.

@garfonso
Hallo Garfonso,

ich habe die 2.4 jetzt auch zum testen installiert?
Habe wie dock07 keine Änderung zur 2.3.2 bei dem Startverhalten festgestellt.
Auch mein dauerhaft auf 3,3V gelegter Eingang GPIO17 ist erst false und wird erst später true.
Edit 11.03.25

Der Eingang blieb über 20min auf false obwohl eindeutig true.
Habe das 10 mal wiederholt. 9 mal falsch. Sobald ich die 3,3V wegnehme und wieder anlege funktioniert es sofort.
Nur beim Start der rpi2 Instanz und bereits vorher angelegten 3,3V wird der falsche Wert false anstatt true angezeigt.
Das ist auch auf allen meinen Eingängen so.
Wenn ich was testen soll sag Bescheid.

LG
Horst

@dock07 sagte in Test Adapter rpi2 2.x:

@garfonso >Bei nur "Ausgang" macht der Adapter beim start gar nichts|<

Kann ich so nicht bestätigen. In dem Moment beglückt mich der GPIO beim Start mit einem unerwünschten "true", eigentlich genau so wie bei eingestelltem Anfangswert 1

mit Ausgang Anfangswert 0 kommt es bei mir, und wahrscheinlich z.B. auch bei @Hasont, zu dem ungewünschten false true false bei Neustart.

Ohne die Initialisierung des jeweiligen GPIO durch den Adapter bleibt dieser auf null/ false, also so wie von mir gewünscht.

@Garfonso
@dock07
Hallo, also bei mir in der 2.3.2 ist es genau so wie bei dock07.
Wie bereits weiter oben schon mal geschrieben sind mir folgende Dinge aufgefallen:
1.) Startverhalten mit false/true/false bei Ausgang = 0
2.) Wenn ich den rpi2 Prozess pausiere und den Raspie neu reboote bleibt alles false wie es sein soll!
Starte ich den rpi2 Prozess wieder gehen alle Relaise auf true/false.
3.) Wenn ich bei Ausgang = Ausgang 4 GPIOs der Relais 1-4 auf true stelle und 4 GPIOs der Relaise 5 - 8 auf false und dann die Instanz rpi2 neu starte werden erstmal alle Ausgänge auf true gesetzt und die GPIOs der Relais 1 - 4 bleiben true und die GPIOs der Relais 5 - 8 gehen true/false. Die GPIOs der Relais 5 - 8 werden somit auch erstmal falsch auf true gesetzt.
Meine Relaise sind true wenn an den GPIOs 3,3V anliegen. So ist es Standard beim Raspie.

Bei den Eingängen ist es bei mir tatsächlich so, dass ein mit 3,3V dauerhaft auf true gesetzter Eingang manchmal für eine ganze Zeit lang nach Reboot vom Raspie oder der rpi2 Instanz als false im Objekt ansteht. Das ändert sich komischerweise erst wenn irgendein Trigger anliegt. Ich hab das bisher nur in den Objekten beobachtet. Trigger kann eine geschaltete Neonröhre oder ein Login über die App sein.
Ev. könnte ich da ja mal den Status mit pinctrl im Raspi selbst abfragen.

Ich kann das leider nur schlecht beschreiben da es nicht sauber nachvollziehbar ist.

@dock07 sagte in Test Adapter rpi2 2.x:

@hasont: False/True/False nach Systemstart, hier mal etwas Dramatik in 2.3.2. Nach reboot zieht bei mir ein 200A Batterie-Schütz lautstark an um nach ein paar ms mit einem Lichtbogen wieder in die bei Start eigentlich gewünschte Ruheposition zu gehen. Für GPIO-Ausgänge habe ich definierte true/false Zustände erst mal in Bookworm ohne rpi2 über Blockly und simple-ssh bash-Scripts mit pinctrl erreicht. Wieder mal so viel vergeudete Zeit. Mittlerweile bekomme ich ein flaues Bauchgefühl vor Updates auf den Raspberry's.

Hallo dock07,

hättest du ev. noch ein paar Infos zum Thema simple-ssh-Scripts und Auszug vom Blockly bzw. Script.
Ev. kann ich das ja auch mal probieren. Das mit pinctrl klappt ja ganz gut. Angeblich kann man ja megrere GPIOs auf einmal abfragen was ich aber so nicht hinbekommen habe. Bei mir ging immer nur einer.