@haus-automatisierung @tt-tom @david-g

juhu ... ich habs geschaft.
Nachdem ich nocheinmal ein factory reset gemacht habe und die Generic eingeschaltet habe (das geht zuverlässig offenbar nur nach factory reset). Alles andere war richtig eingestellt.

Herzlichen Dank für die Unterstützung

@muellerjm der einzige sinnvolle weg geht über einen simplen trigger ... da ist auch nichts unübersichtlich - eher wirds unübersichtlich wenn du mit irgendeinen komischen Versuch es zu umgehen was abenteurliches strickst.
Das hoch komplexe blockly schaut dann so aus ...

@danielos ich habs so gelöst, dass ich 3 Datenpunkte schreibe: Tesla ist daheim über die Positionsdaten aus dem Adapter, Tesla ist angesteckt über den Kabeltyp aus dem Adapter (ein Alias macht den Kabeltyp IEC zu true), Tesla ist ladebereit (SOC aus Adapter unter Soll SOC aus dem Adapter) -> somit weis mein script - bei allen drei True, er steht daheim und kann geladen werden. Erst wenn die PV dann meldet, dass genug Einspeisung da, frage ich den Tesla wieder ob er noch immer was braucht. Damit wird der Tesla nicht geweckt und somit auch kein Ladeverlust

@Homoran
Danke
ich habs neu aufgesetzt mit neuer Karte ... war zwar viel arbeit aber jetzt gehts wieder

@shogun82 Probier mal chargeportdooropen … laut api öffnet das den chargeport oder entriegelt das Kabel

@haus-automatisierung also ich bin dir unendlich dankbar für die tolle Arbeit … für den Shelly Adapter und den Master Kurs … echt genial für alle Nichtprofis.

@drboom hab soeben ein script dazu gemacht - funktioniert anstandslos ... true aktiviert, false deaktiviert

@alteente eigentlich braucht man nur den Stecker in der Ghoma App mit dem WLAN verbinden und den Adapter neu starten ... dann sind zumindest bei mir alle da

@lebeart ich habe für diese Steuerung schon vor geraumer Zeit auf evcc umgestellt und dies in den iobroker eingebunden. Es funktioniert auch mit der neuen Tesla Anmeldung, verlangt aber ein Sponsoring (2€/ Monat reichen da) über github.

@uli977 war bei mir das Gleiche, hab die Token erneuert - jetzt gehts wieder normal

@arteck
nein auch da wird nicht bestätigt, ich habs in allen Varianten versucht

@arteck
es macht keinen Unterschied ob bestätigt oder nicht. Es funkt auch nicht wenn ich den Wert direkt im DP im Admin ändere

Hallo zusammen,

ich betreibe den ioBroker-Modbus-Adapter im Slave-Modus (Modbus-ID 2) auf Port 1503, um Werte an ein externes Gerät (TA CMI) zu liefern.
Die Kommunikation funktioniert grundsätzlich einwandfrei – bestehende Datenpunkte (Coils) lassen sich erfolgreich lesen.
Nun habe ich einen neuen Coil (Adresse 13) angelegt, aber der gesetzte Wert wird weder vom CMI noch per mbpoll als 1 erkannt.

Details zum Problem:
ioBroker: modbus.0 läuft im Slave-Modus, Port 1503, Modbus-ID 2
Coil angelegt unter Adresse 13, write: true, read: true, poll: false, keine Abfrage, kein CW

Datenpunkt: modbus.0.coils.13_Test13

Per JavaScript oder GUI setze ich:

setState("modbus.0.coils.13_Test13", true, true);

Im Objektbaum erscheint der Wert als true (✓)

Aber per mbpoll erhalte ich immer nur [13]: 0

mbpoll -m tcp -a 2 -r 13 -c 1 -t 0 -p 1503 192.168.xxxx

Auch das CMI liest dauerhaft 0

Adapterlog zeigt keine Fehler, Coil existiert (kein „outside coils boundaries“)

Bereits geprüft:

Adapter ist aktiv
Objekt wurde mehrfach neu angelegt und korrekt konfiguriert
Adapter wurde neu gestartet
ioBroker selbst ebenfalls neu gestartet
Redis läuft stabil
Kein Schreibschutz aktiv

Vergleich mit funktionierenden Coils auf anderen Adressen zeigt: nur dieser funktioniert nicht

Frage:
Gibt es bekannte Probleme mit neu angelegten Coils im Modbus-Slave-Modus, die sich korrekt setzen lassen, aber vom Adapter nicht im Speicher gehalten werden?

Danke vorab!
Peter

@haus-automatisierung , @MCU

Danke Mathias, genau das wars ...

#!/bin/bash
for DateiPfad in "$@"
do
  DateiName=$(basename "$DateiPfad")
  if [ "$DateiName" = "AktuellePatienten.csv" ]; then
    /usr/bin/scp "$DateiPfad" pi@192.xxxx:/tmp/AktuellePatienten.csv
    /usr/bin/ssh pi@192.xxxx "
      iobroker file write /tmp/AktuellePatienten.csv 0_userdata.0/CSV/AktuellePatienten.csv && rm -f /tmp/AktuellePatienten.csv
    "
    rm -f "$DateiPfad"
  fi
done

genauso flutscht es

Hi
ich möchte folgendes umsetzen:

• Datei als CSV vom Mac mit Schnellaktion und scp an Iobroker senden (Benutzerdaten/CSV/)
• Dort Trigger entweder mit onfile oder über Triggerdatenpunkt via ssh auslösen
• Datei in ein JSON mit einem script umwandeln

Das müsste doch so funktionieren ... tut es aber nicht. Trigger wird ausgelöst, Datei aber nicht geändert

#!/bin/bash
for f in "$@"
do
  /usr/bin/scp "$f" pi@192.xxxx:/opt/iobroker/iobroker-data/files/0_userdata.0/CSV/AktuellePatienten.csv
  /usr/bin/ssh pi@192.xxxx "
    sleep 2;
    iobroker state set 0_meine_Daten.0.sevenio.Datei_Hochgeladen_Trigger true;
  "
done

auch damit bin ich nicht weitergekommen:

#!/bin/bash
for f in "$@"
do
  /usr/bin/scp "$f" pi@192.xxxx:/tmp/AktuellePatienten.csv
  /usr/bin/ssh pi@192.xxxx "
    iobroker file write 0_userdata.0/CSV/AktuellePatienten.csv /tmp/AktuellePatienten.csv;
    sleep 2;
    iobroker state set 0_meine_Daten.0.sevenio.Datei_Hochgeladen_Trigger true;
  "
done

Admin v 7.6.3
Hat jemand eine Idee?

@foxriver76 sorry, ich hab noch nicht rückgemeldet. Ich habe neu installiert und alles upgedatet. nun gehts wieder problemlos

@homoran yep

@thomas-braun
ich hab ihn über die raspi-config auf den Namen gestellt den der pi vorher hatte.
nach iob stop habe ich den 2. host mit

iobroker host remove pi4iobroker

wegbekommen.
So wies aussieht läuft jetzt alles.

Danke für Deine Unterstützung

@thomas-braun ich habe ihn zurückbenannt, jetzt läuft er wieder, zeigt unter hosts aber zewi an

wie kriege ich den zweiten weg?

@thomas-braun
ich hab wohl einen Fehler entdeckt ... ich hatte den host namen geändert ... war offenbar eine blöde idee.