depict by ip fails with current master 11.2.24 22:30

[AnHardt]

e3@openE3:~/open3e $ python3 Open3E_depictSystem.py -d 10.83.83.1
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
ECU found: 0x680 : HMUMASTER
Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 77, in scan_cobs
    response = client.send_request(
  File "/home/e3/.local/lib/python3.9/site-packages/udsoncan/client.py", line 2164, in send_request
    self.conn.send(payload)
  File "/home/e3/.local/lib/python3.9/site-packages/udsoncan/connections.py", line 80, in send
    self.specific_send(payload)
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/connectors.py", line 43, in specific_send
    self._connection.send_diagnostic(bytearray(payload))
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/client.py", line 720, in send_diagnostic
    raise IOError(
OSError: Diagnostic request rejected with negative acknowledge code: 3

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 313, in <module>
    lstEcus = scan_cobs(startcob, lastcob)
  File "/home/e3/open3e/Open3E_depictSystem.py", line 96, in scan_cobs
    raise Exception(e)
Exception: Diagnostic request rejected with negative acknowledge code: 3

on a PI3 with standard (updated) install .

[philippoo66]

ok, thank you. unfortunately by mistake I just updated the depictSystem in the master branch by the depict_all_python, so I'm not sure if you picked that one or the older one (still in develop branch). Can you please tell me if your Open3E_depictSystem looks

like this (new, master, all_python)

or like this (old, develop)

Also it would be nice if you could give the 'other' version a try and see (and tell) if the behaviour is the same or not.

thank you!

[AnHardt]

It looked like like line 28 (master @ a03133c)

from udsoncan.connections import PythonIsoTpConnection

With Line 26 (develop @ f9a6261

from udsoncan.connections import IsoTPSocketConnection

i get

e3@openE3:~/open3e $ python3 Open3E_depictSystem.py -d 10.83.83.1
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
ECU found: 0x680 : HMUMASTER
Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 76, in scan_cobs
    response = client.send_request(
  File "/home/e3/.local/lib/python3.9/site-packages/udsoncan/client.py", line 2164, in send_request
    self.conn.send(payload)
  File "/home/e3/.local/lib/python3.9/site-packages/udsoncan/connections.py", line 80, in send
    self.specific_send(payload)
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/connectors.py", line 43, in specific_send
    self._connection.send_diagnostic(bytearray(payload))
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/client.py", line 720, in send_diagnostic
    raise IOError(
OSError: Diagnostic request rejected with negative acknowledge code: 3

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 284, in <module>
    lstEcus = scan_cobs(startcob, lastcob)
  File "/home/e3/open3e/Open3E_depictSystem.py", line 95, in scan_cobs
    raise Exception(e)
Exception: Diagnostic request rejected with negative acknowledge code: 3

what is looking pretty similar.

[philippoo66]

I wonder why it's doing a send_diagnostic(). the read is a common service request. I'm afraid udsoncan got confused again...

[AnHardt]

Sorry. Verstehe nur 'Bahnhof'. Das sind meine ersten Schritte mit 'open3e' an meiner 'PT2 BSZ'. Basic, Pascal, C, C++, git, Arduino, 6502, AVR, ST32, ESP32, HA sind mir ziemlich geläufig (wenn auch z.T. etwas eingerostet) aber mit Python und seinen Libraries stehe ich noch ziemlich auf Kriegsfuß.

[AnHardt]

Wenigstens die IP scheint korrekt zu sein. Wenn dass, WLAN down ist erhalte ich

e3@openE3:~/open3e $ python3 Open3E_depictSystem.py -d 10.83.83.1
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 284, in <module>
    lstEcus = scan_cobs(startcob, lastcob)
  File "/home/e3/open3e/Open3E_depictSystem.py", line 63, in scan_cobs
    conn = DoIPClientUDSConnector(DoIPClient(args.doip, tx))
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/client.py", line 191, in __init__
    self._connect()
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/client.py", line 766, in _connect
    self._tcp_sock.connect((self._ecu_ip_address, self._tcp_port))
TimeoutError: [Errno 110] Connection timed out

Normalerweise benutze ich auf 'github' english' (wegen der Reichweite) aber hier scheint die Mehrheit der Entwickler Deutsch zu sprechen. Gibt es eine bevorzugte Sprache für Issues oder Code (comments)?

Normally I do use (a kind of ) Englisch on 'github' (to increase the reach). Is there a preferred language for issues and or code here?

[philippoo66]

wir benutzen hier mehrheitlich deutsch weil die meisten Viessmann Geräte auch in D-Land stehen. googel translate is inzwischen so gut, dass die andren das wohl auch lesen können, und wer will kann ja englisch.

open3e benutzt https://github.com/pylessard/python-udsoncan (findest du glaubich unter /etc/pythonX.y/udsoncan) und das benutzt canisotp oder so und diop (stehen daneben).

da is allerdings 'Leben drin' , es ändert sich ständig und es gibt auch immer Versions-Inkompatibilitäten. Vor etwa 1 Woche hatte noch jemand freudig verkündet, dass das ('alte') depictSystem im AccessPoint Mode top funktioniert...

Ich kann leider nicht debuggen, weil ich garkein One Base Gerät habe und bei meiner Optolink nichtmal ein Vitoconnect dran. Ich habe mir eine virtuelle E3 gebaut, aber die kommuniziert nur auf dem virtuellen CAN Bus...

Wir müssen schauen, wie wir da weiter kommen. Hast du ein Python Debug Tool auf dem System, wo du vlt weitere Infos mit 'ermitteln' könntest?

[philippoo66]

lass mal das depictSystem weg und versuch's direkt mit open3e client. les da mal den DP BusIdentification aus

python3 Open3Eclient.py -d 192.168.xy.za -r 256 -v

wenn ich nix vergessen hab....

[AnHardt]

Das scheint zu klappen. 'maser' und 'develop' produzieren die selbe Ausgabe ohne Fehlermeldung.

e3@openE3:~/open3e $ python3 Open3Eclient.py -d 10.83.83.1 -r 256 -v 
None 256 BusIdentification {"BusAddress": 1, "BusType": {"ID": 2, "Text": "CanInternal"}, "DeviceProperty": {"ID": 2, "Text": "HMUMASTER"}, "DeviceFunction": {"ID": 2, "Text": "HMUMASTER"}, "SW-Version": "2.513.1932.372", "HW-Version": "2.606.105.2", "VIN": "012_changed_3456"} 
closing 0x680 - bye!

Auch die Außentemperatur (247) lässt sich auslesen '4,2°C' und ist die gleich wie in ViCare! Werde jetzt mal schauen welche der für mich wichtigen und nicht in ViCare oder HA vorhandenen Daten ich noch finden kann und danach entscheiden ob ich mir einen Can-Adapter zulege.

Danke einstweilen.

[philippoo66]

edit: alles blödsinn, du hast ja noch garkeinen CAN Adapter :-/

@AnHardt

hier ist ein uraltes bash Skript mit dem du Datenpunkte scannen könntest (wenn du viel Zeit hast ;-)

# DID Scan 
#
# -> candump can0 > candump.log
# -> bash didscan

set -ex
for did in {256..3500}
do
    cansend can0 680#0322$(printf '%04X' $did)00000000
    sleep 1
done

die Pause nicht verkürzen! Die braucht es für ein Timeout bei langen Antworten/Daten, sonst kommt alles durcheinander...

Vorher einen candump starten mit Filter auf 680, 690.

da, wo eine positive Antwort kommt, ist ein Datenpunkt.

Ich hab auch noch 'Tools' zum Auswerten des outputs, wenn du nicht alles 'von Hand' durchgehen willst.

Grüsse! Phil

[AnHardt]

Danke für Deine Mühen. Habe in der 'Open3Edatapoints.py' ein paar der interessanten Einträge gesucht und abgefragt - die meisten warten auf meiner Anlage vorhanden. Nach ein wenig copy/paste in der 'Open3Edatapoints.py' konnte ich Temperaturen und Gas-Statistiken für die FuelCell auch sinnvoll interpretieren lassen. Das ist erstmal motivierend genug um Can-Adapter, Stecker91, Hutschienengehäuse, Netzteil, ... zu bestellen. Bis dahin.

[philippoo66]

kannst du dein copy&paste Arbeit bitte posten oder noch besser in die 'offizielle' datapoints.py einbauen!?

[philippoo66]

im Viessmann Forum hat grad wer den CAN Adapter gekauft, aber wohl eine Optolink Anlage. Leider ist der wohl im Ausland angesiedelt (englische Konversation), sonst hättest du ihm den Adapter bestimmt günstig abkaufen können ;-)

[wotandamm]

Ich habe die neuste Master Version geladen und die alte mit sudo systemctl stop open3e gestoppt.

Dann habe ich das depict versucht und folgendes erhalten:

python3 Open3E_depictSystem.py read DID enums ... 2951 DIDs listed. scan COB-IDs 0x680 to 0x6ff ... Traceback (most recent call last): File "/home/petkow/open3e/Open3E_depictSystem.py", line 313, in lstEcus = scan_cobs(startcob, lastcob) File "/home/petkow/open3e/Open3E_depictSystem.py", line 67, in scan_cobs bus, conn = get_pycan_conn(can=can, ecurx=rx, ecutx=tx) File "/home/petkow/open3e/Open3E_depictSystem.py", line 288, in get_pycan_conn stack = isotp.CanStack(bus=bus, address=tp_addr, params=isotp_params) # Network/Transport layer (IsoTP protocol) File "/home/petkow/.local/lib/python3.9/site-packages/isotp/protocol.py", line 1108, in init TransportLayer.init(self, rxfn=self.rx_canbus, txfn=self.tx_canbus, *args, **kwargs) File "/home/petkow/.local/lib/python3.9/site-packages/isotp/protocol.py", line 480, in init self.params.set(k, params[k], validate=False) File "/home/petkow/.local/lib/python3.9/site-packages/isotp/protocol.py", line 331, in set setattr(self, key, val) AttributeError: 'Params' object has no attribute 'override_receiver_stmin' SocketcanBus was not properly shut down

was muss noch gestoppt werden?

[MyHomeMyData]

@wotandamm Du musst die Bibliotheken updaten:

pip3 install -r requirements.txt

Anschließend sollte es funktionieren.

[AnHardt]

Ich bin ein gutes Stück weiter. Mit den Tipps von Sonntag aus der Diskussion 59 habe ich ein depict hin bekommen.

Mit dem neueste 'master'='devolopment' Branch bekam ich immer noch:

e3@openE3:~/open3e $ python3 Open3E_depictSystem.py -d 10.83.83.1
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x688 ...
1664
ECU found: 0x680 : HMUMASTER
1665
Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 77, in scan_cobs
    response = client.send_request(
  File "/home/e3/.local/lib/python3.9/site-packages/udsoncan/client.py", line 2143, in send_request
    self.conn.send(payload)
  File "/home/e3/.local/lib/python3.9/site-packages/udsoncan/connections.py", line 79, in send
    self.specific_send(payload)
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/connectors.py", line 43, in specific_send
    self._connection.send_diagnostic(bytearray(payload))
  File "/home/e3/.local/lib/python3.9/site-packages/doipclient/client.py", line 720, in send_diagnostic
    raise IOError(
OSError: Diagnostic request rejected with negative acknowledge code: 3

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/e3/open3e/Open3E_depictSystem.py", line 313, in <module>
    lstEcus = scan_cobs(startcob, lastcob)
  File "/home/e3/open3e/Open3E_depictSystem.py", line 96, in scan_cobs
    raise Exception(e)
Exception: Diagnostic request rejected with negative acknowledge code: 3

Dafür habe ich 'Open3E_depictSystem.py' folgendermaßen gepatcht: ip-patch

Danach ist ist es durchgelaufen.

Da das Can-Interface inzwischen da und provisorisch installier ist, das gleiche noch mal für can. can-patch

Mein momentaner Stand der Dinge ist auf meinem PT2_branch zu sehen. Leider setzt der auf dem 'master' von letzte Woche auf. Das mach ich nochmal in richtig.

[philippoo66]

Moin @AnHardt !

Erstmal danke! Ich fürchte aber, das ist nicht so richtig die Lösung. Normalerweise kommt, wenn keine ECU an einer Adresse ist, einfach ein Timeout - es antwortet halt nix wo nix ist. Wenn da jetzt was antwortet, aber mit einem seltsamen Fehlercode, scheint da ja was zu sein. Wir sollten die Adresse / die ECU nicht einfach ignorieren.

Kannst du bitte noch mal sagen, wie viele Geräte (und was für welche) an dem Bus hängen?

Pier Yves hat eine 'saubere' Möglichkeit geschaffen, Datenpunkte ohne Codec (genauer gesagt ohne Kenntnis der Datenlänge) zu lesen - vielleicht sollte ich das depict mal da drauf umbauen. Mit der bestehenden Variante 'missbrauche' ich eigentlich eine interne Funktion. Vielleicht schafft uns das Probleme, die bei alten Versionen von udsoncan nicht 'aufpoppten'...

[philippoo66]

ps. du hast da Sachen öffentlich online mit Seriennummern und Passworten, die würde ich vlt runter nehmen

[AnHardt]

Inzwischen habe ich mal im Menü der Anlage nachgeschaut was die Anlage meint an Komponenten zu kennen und abgeschriben. Die aus dem 'depict' bekannten 'Bussname' und 'ecuAdr' habe ich mal dazu gedichtet. Wie kann ich aus der Bussadresse die ecuAdr bestimmen? Beim scannen über CAN fliegt mir immer noch die '1671' um die Ohren. Über IP scanne ich nicht mehr, dazu müsste ich mich ja jedes mal vom Viessmann Server trennen.

{
"DiscoveredDevices" : {

  "HMU-Master" : {
    "Bussadresse": 1,
    "ecuAdr" : "0x680-1664",
    "Busstyp": 2, 
    "Busname" : "CanInternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "2.513.1932.372",
    "HW-Version": "2.606.105.2"
  },
  "BCU" : {
    "Bussadresse": 50,
    "ecuAdr" : "0x688-1672",
    "Busstyp": 2, 
    "Busname" : "CanInternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "5.518.1929.111",
    "HW-Version": "1.600.500.1"
  },
  "Gebläse" : {
    "Bussadresse": 60,
    "ecuAdr" : "?",
    "Busstyp": 2, 
    "Busname" : "CanInternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "0.2.2.0",
    "HW-Version": "0.0.0.0"
  },
  "Brennstoffzelle" : {
    "Bussadresse": 94,
    "ecuAdr" : "?",
    "Busstyp": 3, 
    "Busname" : "CanExternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "0.1.1.0",
    "HW-Version": "0.0.12.0"
  },
  "HMI" : {
    "Bussadresse": 59,
    "ecuAdr" : "0x684-1668",
    "Busstyp": 2, 
    "Busname" : "CanInternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "6.525.2016.0",
    "HW-Version": "3.503.303.2"
  },
  "Backend-Gateway" : {
    "Bussadresse": 58,
    "ecuAdr" : "?",
    "Busstyp": 2, 
    "Busname" : "CanInternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "10.504.2113.2",
    "HW-Version": "10.1.2.0"
  },
  "27" : {
    "Bussadresse": 97,
    "ecuAdr" : "?",
    "Busstyp": 3, 
    "Busname" : "CanExternal",
    "Herstellernummer": "*redacted*",
    "SW-Version": "0.0.2.257",
    "HW-Version": "86.17735.0.27"
  },
  "M2IO" : {
    "Bussadresse": 32,
    "ecuAdr" : "?",
    "Busstyp": 1, 
    "Busname" : "PlusBus",
    "Herstellernummer": "*redacted*",
    "SW-Version": "6.506.1841.62",
    "HW-Version": "65535.1.1.65535"
  }
}
}

[philippoo66]

moin @AnHardt !

Wie kann ich aus der Bussadresse die ecuAdr bestimmen?

wenn wir das wüssten... da gibt es ein paar Sachen, die wir noch nicht durchblicken.

hier https://github.com/open3e/open3e/discussions/59#discussioncomment-8506111 hatte jemand ein ähnliches Problem beim Scannen. du kannst mal oben im depict (aktuell Zeile 55) die 'Problemadresse' 1671 ausschliessen lstskips = [1671] aber wenn es dann bei einer weiteren hängen bleibt ist das auch keine Lösung (eine Lösung ist es eh nicht).

Irgendwas scheint Viessmann geändert zu haben, so komische Rückgabewerte hatten wir früher nicht...

Grüsse! Phil

[philippoo66]

hast du zufällig ioBroker im Einsatz und könntest Jürgens Adapter ausprobieren? der macht auch einen System Scan. Wäre interessant zu wissen, ob der durchläuft...

https://github.com/MyHomeMyData/ioBroker.e3oncan

[AnHardt]

Die '1671' habe ich schon lange, außer für Tests, ausgeschlossen Nein. Leider kein 'ioBroker', ich benutze 'Home Assistant'. Ich vermute bei der '1671' bandelt es sich um die Brennstoffzelle, die ja auch auf dem internen CAN-Buss sein soll. Die ist von Viessmann bei Pannasonic zugekauft und spricht möglicherweise einen asiatischen Dialekt.

Ist aber auch nicht soo tragisch. Die allermeisten relevanten Dids der BSZ bekomme ich auch über die 0x680. Eigentlich vermisse ich nur:

        1795 : RawCodec(1, "FuelCellRuntimePrediction"),
        1798 : RawCodec(1, "FuelCellHoursTillNextStart"),

Aber, am Freitag kommt der Service (Zelle steht schon seit Weihnachten mit dem berüchtigten 'C2F0 F.303'). Hoffentlich bringt er das Ding wieder in Gang und spielt ein paar Softwareupdates ein. Drück mir die Daumen.