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

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

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

@smallfeuer sagte in Test Adapter rpi2 2.x:

@hasont sagte in Test Adapter rpi2 2.x:
pullUpWarning/hidden

Hast du Pullup / Pulldown ein Haken gesetzt? Nein, alle ohne
Oder nur von True mal auf false geändert ? wenn ja, dann mit Bestätigung? Nein

Ich fasse kurz zusammen - heißt bei dir bleibt der Eingang die ganze Zeit auf True! Ich werde mal meinen Magnetschalter überbrücken um die Verbindung zu optimieren. Mal schauen ob der vielleicht zu viel Widerstand hat. Auch wenn ich mir das nicht vorstellen kann- da er ja sonst dauerhaft stabil ein True bringt.

Hab grad im Objekt nachgesehen und mein GPIO 17 war False. Bin in den Keller um zu sehen ob ich ev. die Krokoklemme schon abgeklemmt habe >> Nein war noch geschaltet.
Dann schau ich in den PC und der GPIO 17 ist wieder True (hab nur Licht eingeschaltet)
Ich bleib da mal für dich dran!

Edit 27.02 21:00: Grad mal alle Eingänge auf 1000ms gesetzt um zu sehen ob der Eingang GPIO 23 beim Licht einschalten (Neon) noch kommen.
In Instanz rsp2 abgespeichert und jetzt ist GPIO 17 FALSE, Eingang noch an 3,3V Leider kein log!!

Edit:28.02 10:38 Gerade nachgesehen und GPIO ist wieder True > Log eingeschaltet und Instanz neu gestartet.

GPIO 17 war wieder False 2025-02-28 10:21:11.461 und ist dann 2025-02-28 10:28:55.677 auf True
Der GPIO 17 ist dauerhaft an 3,3V

Hier das Logfile von 10:21 - 10:36

02

Log-Größe: 25.2 MB
Zeit
	
rpi2.0
	2025-02-28 10:36:57.654	debug	Ignoring change event due to debounce: 7ms < 1000.
rpi2.0
	2025-02-28 10:36:57.653	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:36:57.647	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:36:57.646	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:35:57.650	debug	Ignoring change event due to debounce: 5ms < 1000.
rpi2.0
	2025-02-28 10:35:57.649	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:35:57.646	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:35:57.645	debug	GPIO change on port 23: false
ebus.0
	2025-02-28 10:35:06.748	info	all history done
ebus.0
	2025-02-28 10:35:06.717	info	all http done
ebus.0
	2025-02-28 10:35:06.661	info	installed ebusd version is 24.1
rpi2.0
	2025-02-28 10:34:57.652	debug	Ignoring change event due to debounce: 5ms < 1000.
rpi2.0
	2025-02-28 10:34:57.651	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:34:57.649	debug	Ignoring change event due to debounce: 2ms < 1000.
rpi2.0
	2025-02-28 10:34:57.648	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:34:57.647	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:34:57.646	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:33:57.652	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:33:57.651	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:32:57.652	debug	Ignoring change event due to debounce: 11ms < 1000.
rpi2.0
	2025-02-28 10:32:57.651	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:32:57.651	debug	Ignoring change event due to debounce: 10ms < 1000.
rpi2.0
	2025-02-28 10:32:57.650	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:32:57.649	debug	Ignoring change event due to debounce: 8ms < 1000.
rpi2.0
	2025-02-28 10:32:57.648	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:32:57.641	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:32:57.640	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:31:57.651	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:31:57.651	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:30:57.653	debug	Ignoring change event due to debounce: 7ms < 1000.
rpi2.0
	2025-02-28 10:30:57.652	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:30:57.646	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:30:57.645	debug	GPIO change on port 23: false
ebus.0
	2025-02-28 10:30:06.758	info	all history done
ebus.0
	2025-02-28 10:30:06.725	info	all http done
ebus.0
	2025-02-28 10:30:06.666	info	installed ebusd version is 24.1
host.raspberrypi
	2025-02-28 10:30:00.027	warn	instance system.adapter.ebus.0 already running with pid 1127
rpi2.0
	2025-02-28 10:29:57.653	debug	Ignoring change event due to debounce: 11ms < 1000.
rpi2.0
	2025-02-28 10:29:57.652	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:29:57.645	debug	Ignoring change event due to debounce: 3ms < 1000.
rpi2.0
	2025-02-28 10:29:57.644	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:29:57.642	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:29:57.641	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:28:55.679	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:28:55.679	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:28:55.678	debug	Setting state for port 17 to true
rpi2.0
	2025-02-28 10:28:55.677	debug	GPIO change on port 17: true
rpi2.0
	2025-02-28 10:27:57.653	debug	Ignoring change event due to debounce: 9ms < 1000.
rpi2.0
	2025-02-28 10:27:57.652	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:27:57.644	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:27:57.643	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:26:57.652	debug	Ignoring change event due to debounce: 6ms < 1000.
rpi2.0
	2025-02-28 10:26:57.651	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:26:57.649	debug	Ignoring change event due to debounce: 3ms < 1000.
rpi2.0
	2025-02-28 10:26:57.648	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:26:57.646	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:26:57.645	debug	GPIO change on port 23: false
ebus.0
	2025-02-28 10:25:06.851	info	all history done
ebus.0
	2025-02-28 10:25:06.819	info	all http done
ebus.0
	2025-02-28 10:25:06.751	info	installed ebusd version is 24.1
rpi2.0
	2025-02-28 10:24:57.639	debug	Setting state for port 23 to false
rpi2.0
	2025-02-28 10:24:57.639	debug	GPIO change on port 23: false
rpi2.0
	2025-02-28 10:21:11.627	debug	Port 23 direction: in
rpi2.0
	2025-02-28 10:21:11.576	debug	Setting state for port 22 to false
rpi2.0
	2025-02-28 10:21:11.575	debug	Port 22 direction: in
rpi2.0
	2025-02-28 10:21:11.574	debug	Port 21 direction: outlow
rpi2.0
	2025-02-28 10:21:11.573	debug	Port 20 direction: outlow
rpi2.0
	2025-02-28 10:21:11.571	debug	Port 19 direction: outlow
rpi2.0
	2025-02-28 10:21:11.521	debug	Setting state for port 18 to false
rpi2.0
	2025-02-28 10:21:11.519	debug	Port 18 direction: in
rpi2.0
	2025-02-28 10:21:11.461	debug	Setting state for port 17 to false
rpi2.0
	2025-02-28 10:21:11.458	debug	Port 17 direction: in
rpi2.0
	2025-02-28 10:21:11.457	debug	Port 16 direction: outlow
rpi2.0
	2025-02-28 10:21:11.455	debug	Port 13 direction: outlow
rpi2.0
	2025-02-28 10:21:11.454	debug	Port 12 direction: outlow
rpi2.0
	2025-02-28 10:21:11.453	debug	Got chip: class Default extends classes_1.Device {}
rpi2.0
	2025-02-28 10:21:11.453	debug	Got 4 from Raspberry Pi 4 Model B Rev 1.2code_text
host.raspberrypi
	2025-02-28 10:21:04.831	info	stopInstance timeout system.adapter.rpi2.0 killing pid 3483

Edit 2.03 16:43 Musste IOB gestern und heute mehrfach starten. Mein GPIO 17 war danach immer False und ging nach unbestimmter Zeit dann auf True. Irgendwie scheint es so als würde er auf einen Trigger warten. Grad war es direkt nach einem VIS-Login.

rpi2.0
	2025-03-02 16:40:18.648	debug	Setting state for port 23 to false
rpi2.0
	2025-03-02 16:40:18.648	debug	GPIO change on port 23: false
rpi2.0
	2025-03-02 16:40:18.648	debug	Ignoring change event due to debounce: 0ms < 1000.
rpi2.0
	2025-03-02 16:40:18.648	debug	GPIO change on port 17: true
rpi2.0
	2025-03-02 16:40:18.648	debug	Setting state for port 17 to true
rpi2.0
	2025-03-02 16:40:18.647	debug	GPIO change on port 17: true
web.0
	2025-03-02 16:40:16.242	info	==> Connected system.user.admin from ::ffff:192.168.1.104
web.0
	2025-03-02 16:40:15.951	info	<== Disconnect system.user.admin from ::ffff:192.168.1.104 vis.0
rpi2.0
	2025-03-02 16:40:10.254	debug	Ignoring change event due to debounce: 36ms < 1000.
rpi2.0
	2025-03-02 16:40:10.254	debug	GPIO change on port 23: false

Hab dann den Prozess neu gestartet GPIO 17 wieder False. Im VIS GPIO 25 geändert und sofort kam auch beim GPIO 17 ohne debounce ein True.

rpi2.0
	2025-03-02 16:56:46.083	debug	Setting state for port 23 to false
rpi2.0
	2025-03-02 16:56:46.082	debug	GPIO change on port 23: false
rpi2.0
	2025-03-02 16:56:46.081	debug	Setting state for port 17 to true
rpi2.0
	2025-03-02 16:56:46.081	debug	GPIO change on port 17: true
rpi2.0
	2025-03-02 16:56:46.077	debug	Written true into port 25
rpi2.0
	2025-03-02 16:56:46.077	debug	stateChange for rpi2.0.gpio.25.state found state = {"val":true,"ack":false,"ts":1740931006072,"q":0,"from":"system.adapter.web.0","user":"system.user.admin","lc":1740931006072}