Hallo,
ich habe Infos über mein Auto aus dem VW Carnet in fhem extrahiert.
Nun möchte ich gern einige Angaben über Homebridge in HomeKit übertragen:
- location -> Karte mit Autostandort
- Kilometerstand -> Zahl
- Meldungen des Autos -> String ("AdBlue nachfüllen, noch 800km")
Sowas eben.
Ich finde aber bisher gar kein Mittel, um einfach irgendeinen Text oder irgendeinen Zahlenwert in HomeKit zu übertragen.
Ich muss also vermutlich eigene characteristics erstellen.
Gibt es dazu schon eine umfassende Anleitung? Kann ich mir einfach ein deviceType ausdenken oder gibt es nur wenige vordefinierte?
Homekit unterstützt meines Wissens nur die vordefinierten Charakteristiken und Services... Ich fürchte da wirst du dich schwer tun... (wenn sich bei homekit nicht im letzten Jahr einiges geändert hat)
Hallo,
wie hast du die CarNet Integration denn gemacht?
Kannst du dazu ein paar Tipps geben?
Ich habe auf meinem Raspberrypi eine abgewandelte Version von carnet_py (https://github.com/wez3/volkswagen-carnet-client) (danke an wez3 für die Vorlage) im cronjob laufen, die die Antworten des Dienstes als json String an meinen mosquitto mqtt Broker postet. Die Json strings werden mit einem fhem Modul expandJSON geparst und in einzelne Readings gesplittet. Auf dem Rückweg kann ich auch per Fhem Befehl messages an Car-Net senden, die per python Script in einer CMD line an den Dienst gesendet werden. Leider ist die Eingabe der PIN für schreibende Aktionen wie ,,Standheizung aktivieren" beim Verbrennermodell in den Python Modulen noch nicht vollständig umgesetzt, daher brauchte ich zum Einschalten der Standheizung eine andere Lösung. Ich habe mit Fischertechnik einen Automaten gebaut, der den Knopf drücken kann und habe ihn mit einem batteriebetriebenen Homematic Modul eingebunden. Geht natürlich nur zuhause damit. Das Ding macht aber nun zuverlässig um 06:30 an Werktagen bei unter 6 Grad die Standheizung an. Das geht dann auch per Siri-Command ,,schalte die Heizung in Arteon ein" mittels homebridge. Ausschalten und zwischen Kühlen und Heizen umschalten geht aber auch per API direkt.
Voraussetzungen:
- fhem
- homebridge
- mosquitto mqtt broker (sudo apt-get install mosquitto)
- python3 (ich habe 3.4.2, versuche python3 -V)
- paho mqtt modul für python (pip install paho-mqtt)
Ganz schönes Gefummel:
Klont Euch das Repo hier auf den Raspi:
https://github.com/bgewehr/volkswagen-carnet-client (https://github.com/bgewehr/volkswagen-carnet-client)
Konfig wie in README.md beschrieben.
Test der Konfiguration und der Voraussetzungen auf Python-Seite mit Aufruf im github-Klon-Ordner:
python3 ./we_connect_client.py -u <username> -p <password> -c retrieveCarNetInfo
Müsste Informationen zum Fahrzeug und allerlei Infos ausgeben.
Um MQTT hinzuzufügen und dennoch die Updates von reneboer einfach mitnehmen zu können, habe ich einen kleinen wrapper gebaut names my-car.py, der die Funktionen der we_connect_client.py importiert und eine eigene Funktion mqtt hinzufügt. Der Wrapper kann für alle Aufrufe verwendet werden, es müsste also ebenso gut auch folgendes funktionieren:
python3 ./my-car.py -u <username> -p <password> -c retrieveCarNetInfo
In meiner (root-) Crontab auf dem Raspberry steht folgendes (sudo crontab -e) (muss nicht root sein, dann sorgt für passende Rechte):
*/10 * * * * python3 /home/bananapi/carnet/volkswagen-carnet-client/my-car.py -u <username> -p <password> -c mqtt
Dies führt alle 10 Minuten den python job aus und sendet die Ergebnisse an den installierten MQTT-broker.
In fhem empfange ich die Daten mit einem MQTT device:
MQTT Server bekannt machen:
define MQTT_fhem MQTT <myMqttServerIpOrHostName>:1883
MQTT Device:
define carnet MQTT_DEVICE
attr carnet IODev MQTT_fhem
attr carnet autoSubscribeReadings /carnet/+
Damit stehen die Daten aus dem Carnet als lange JSON Strings zur Verfügung, deswegen breche ich sie mit expandJSON in einzelne Readings auf:
define carnetexpand expandJSON carnet:.*
Das sind viele (!!) Readings.
Hier hole ich mir die wichtigsten zusammen:
define carnet_info readingsGroup carnet:remoteAuxiliaryHeating_status_outdoorTemp carnet:vehicleDetails_distanceCovered carnet:remoteAuxiliaryHeating_status_operationMode carnetHeating:.*
attr carnet_info mapping {'carnet.vehicleDetails_distanceCovered'=>'Kilometerstand','carnet.remoteAuxiliaryHeating_status_outdoorTemp'=>'Aussentemperatur','carnet.remoteAuxiliaryHeating_status_operationMode'=>'Modus Standheizung','carnetHeating.state'=>'Status Standheizung'}
attr carnet_info setList heating_on heating_off heating_cool heating_auto
Außerdem habe ich ein device im Homekit-Raum, welches die wichtigen Parameter bereitstellt und die Zeitsteuerung aktivieren und deaktivieren kann:
define carnetHeating dummy
attr carnetHeating event-on-change-reading state,currentState
attr carnetHeating genericDeviceType thermostat
attr carnetHeating homebridgeMapping clear Model=carnet:completeVehicleJson_model Manufacturer=carnet:vehicleDetails_serviceInspectionData CurrentHeatingCoolingState=currentState,values=off:0;;;;HEATING_on:1;;;;VENTILATION_on:2;;;;AUTOMATIC:3,valud=off TargetHeatingCoolingState=state,values=off:0;;;;HEATING_on:1;;;;VENTILATION_on:2;;;;AUTOMATIC:3,cmds=OFF:off;;;;HEAT:HEATING_on;;;;AUTO:AUTOMATIC;;;;COOL:VENTILATION_on CurrentTemperature=carnet:remoteAuxiliaryHeating_status_outdoorTemp,nochache=1 TargetTemperature=carnet:remoteAuxiliaryHeating_status_outdoorTemp,nocache=1 RotationSpeed=carnet:vehicleDetails_distanceCovered,minValue=0,maxValue=200000,factor=1000,unit= CurrentRelativeHumidity=carnet:vehicleStatusData_fuelRange,minValue=0,maxValue=1100,factor=1,unit=
attr carnetHeating setList off HEATING_on AUTOMATIC VENTILATION_on
Der Dummy wird von einem doif gesetzt:
define carnetHeating_di DOIF ([carnet:remoteAuxiliaryHeating_status_active] eq '1') (setReading carnetHeating currentState [carnet:remoteAuxiliaryHeating_status_operationMode]_on) DOELSE (setReading carnetHeating currentState [carnetHeating])
Damit auch was passiert, wenn man am dummy etwas schaltet, löst dieser doif die entsprechenden Befehle aus:
define carnetAct DOIF ([carnetHeating] eq "VENTILATION_on") (\
"python3 /home/bananapi/carnet/volkswagen-carnet-client/my-car.py -u <username> -p <password> -s <spin> -c startRemoteVentilation >> /home/bananapi/carnet/volkswagen-carnet-client/carnetFhem.log",\
set wdt_uzsu_Arteon_Heizung disable,\
setreading carnetHeating currentState VENTILATION_on\
)\
DOELSEIF\
([carnetHeating] eq "HEATING_on") (\
"python3 /home/bananapi/carnet/volkswagen-carnet-client/my-car.py -u <username> -p <password> -s <spin> -c startRemoteHeating >> /home/bananapi/carnet/volkswagen-carnet-client/carnetFhem.log",\
set Arteon_Heizung on,\
set wdt_uzsu_Arteon_Heizung disable,\
setreading carnetHeating currentState HEATING_on\
)\
DOELSEIF\
([carnetHeating] eq "AUTOMATIC") (\
set wdt_uzsu_Arteon_Heizung enable\
)\
DOELSEIF\
([carnetHeating] eq "off") (\
"python3 /home/bananapi/carnet/volkswagen-carnet-client/my-car.py -u <username> -p <password> -s <spin> -c stopRemoteHeating >> /home/bananapi/carnet/volkswagen-carnet-client/carnetFhem.log",\
setreading carnetHeating currentState off,\
set wdt_uzsu_Arteon_Heizung disable\
)
Ich habe noch eine Google-Maps-Karte hinzugefügt, die mir visualisiert, wo das Auto steht:
defmod n_carnetMap notify carnet:location.* {\
my $url = 'https://maps.google.com/maps?width=700&height=440&hl=en&q='.ReadingsVal('carnet','position_lat',0).','.ReadingsVal('carnet','position_lng',0).'&ie=UTF8&t=&z=16&iwloc=B&output=embed';;;;\
fhem("defmod carnetMap weblink iframe ".$url);;;;\
}
defmod carnetMap weblink iframe https://maps.google.com/maps?width=700&height=440&hl=en&q=0,0&ie=UTF8&t=&z=16&iwloc=B&output=embed
attr carnetMap1 htmlattr width="640" height="480"
Damit ist nun erstmalig auch das Einschalten der Standheizung per VW "API" möglich. Schlüssel zum Einschalten der Standheizung per fhem war bisher Fischertechnik (siehe .mov unten!). Daten lesen geht auch ohne. Bisschen doof ist es, dass Apple keine Eigendefinition von Attributen zulässt und das Auto auch noch nicht als devicetype entdeckt hat. Deswegen steht mein Kilometerstand in der Drehgeschwindigkeit und die Restreichweite in der Luftfeuchtigkeit. Aber was soll's...
## MANUELLE STEUERUNG per Fischertechnik-Automat
Die Homematic-Platine an meinem Fischetechnik-Automaten ist klassisch ein switch:
define Arteon_Heizung CUL_HM XYZXYZ
attr Arteon_Heizung IODev hmlan
Ein Weekdaytimer macht dann die Automation:
define wdt_uzsu_Arteon_Heizung WeekdayTimer Arteon_Heizung en !$we|06:30|on (ReadingsVal("OC3","temperature",0) < 6)
attr wdt_uzsu_Arteon_Heizung commandTemplate set $NAME $EVENT
OC3 ist mein Homematic Wetterfrosch.
ZitatDas sind viele (!!) Readings.
Um die Anzahl der Readings/Events zu reduzieren, kann man bei der Definition des expandJSON Moduls angeben welche Readings angelegt/erzeugt werden. Siehe cref:expandJSON:target_regex (https://fhem.de/commandref.html#expandJSON)
Hallo fhem Community,
versuche im Moment das Car Net in fhem zu bekommen. Folgende Schritte habe ich bereits ausgeführt:
1. Cronjob angelegt: Ich habe in der Datei vw_carnet_web.py Benutzer / Passwort / VIN eingetragen. Diese unter: home/pi/carnet/volkswagen-carnet-client/ abgespeichert.
2. Dann habe ich in die Datei CRONJOB unter /etc/crontab folgendes eingetragen: */10 * * * * python /home/pi/carnet/volkswagen-carnet-client/vw_carnet_web.py mqtt
3. Im Anschluss habe ich MQTT per sudo cpan install Net::MQTT:Simple und sudo cpan install Net::MQTT:Constants installiert.
4. Neustart FHEM
5. MQTT Server per define MQTT_fhem MQTT 192.168.178.3:1883 angelegt
6. Device mit folgenden Attributen erstellt:
define carnet MQTT_DEVICE
attr carnet IODev MQTT_fhem
attr carnet autoSubscribeReadings /carnet/+
Leider erhalte ich nun aber unter dem "carnet" Device keine Readings und ich stehe ein wenig auf dem Schlauch :-)
Fragen:
1. Wie sehe ich ob der Cronjob korrekt ausgeführt / Daten von Car Net erhält? (Wird hier irgendwo eine Datei abgelegt? Muss ich den Cronjob initial noch starten?
2. Unter dem MQTT Server MQTT_fhem steht als Status "disconnected" ist dies so korrekt?
3. Wo sollten die Readings auftauchen? Unter dem carnet Device oder?
Ich freue mich auf Eure Rückmeldung und hoffe, dass ich das Teil noch zum laufen bekomme.
Vielen Dank, Grüße Timo
Habe folgende ausgabe im Syslog zum Cronjob:
Jan 14 09:50:01 raspberrypi CRON[31590]: (fhem) CMD (/home/pi/carnet/volkswagen-carnet-client/vw_carnet_web.py mqtt)
Jan 14 09:50:01 raspberrypi CRON[31586]: (CRON) info (No MTA installed, discarding output)
Hmm Hilfe?
Es läuft,... nun kann ich auch python debuggen,... danke für die Integration,...
Allerdings hänge ich nun am cronjob iser wird wohl aufegrufen laut syslog aber leider bekomme ich kein Update:
Jan 14 15:30:01 raspberrypi CRON[7491]: (pi) CMD (/home/pi/carnet/volkswagen-carnet-client/vw_carnet_web.py mqtt)
Wenn ich als User PI folgendes eingebe python /home/pi/carnet/volkswagen-carnet-client/vw_carnet_web.py mqtt
klappt alles. Hat mir noch jemand ein Tipp versuche gerade die Permissions zu prüfen, verstehe es aber nicht ganz,...
Danke :-)
Hallo,
ich stecke hier auch fest.
Mein cronjob läuft alle 10 Minuten allerdings scheint dieser als user pi ausgeführt zu werden...
Jan 19 15:00:01 raspberrypi CRON[929]: (pi) CMD (python /opt/fhem/carnet/volkswagen-carnet-client/vw_carnet_web.py mqtt)
Ich habe durch diesen Hinweis ein Rechteproblem vermutet.
Bei mir war initial fhem:dialout als Besitzer:Gruppe angegeben.
Ausführbar sollte die Skripts wahrscheinlich schon sein...
Mit...
sudo chmod 777 /opt/fhem/carnet/volkswagen-carnet-client/lib_mqtt.py
sudo chmod 777 /opt/fhem/carnet/volkswagen-carnet-client/vw_carnet_web.py
sollte jeder die Datei ausführen können.
Bei mir hat das aber auch nicht geholfen.
Ich sehe im Gegensatz zu dir auch bei direkter Eingabe keine Rückmeldung. Die Anmeldung bei carnet scheint aber zu funktionieren.
ein
list MQTT_fhem
ergibt
Internals:
CFGFN ./FHEM/00_CARNET.cfg
DEF 127.0.0.1:1883
DeviceName 127.0.0.1:1883
FD 5
NAME MQTT_fhem
NOTIFYDEV global
NR 1928
NTFY_ORDER 50-MQTT_fhem
PARTIAL
STATE opened
TYPE MQTT
buf
msgid 2
ping_received 1
timeout 60
READINGS:
2019-01-19 15:38:44 connection active
2019-01-19 14:51:44 state opened
messages:
ein
list carnet
folgendes
Internals:
CFGFN ./FHEM/00_CARNET.cfg
IODev MQTT_fhem
NAME carnet
NR 1930
STATE ???
TYPE MQTT_DEVICE
READINGS:
2019-01-15 00:12:06 test
2019-01-19 14:52:03 transmission-state subscription acknowledged
message_ids:
sets:
subscribe:
/carnet/+
/carnet/test
subscribeExpr:
^\/carnet\/([^/]+)$
^\/carnet\/test$
subscribeQos:
/carnet/+
/carnet/test 0
subscribeReadings:
/carnet/test:
cmd
name test
Attributes:
IODev MQTT_fhem
autoSubscribeReadings /carnet/+
room carnet
subscribeReading_test /carnet/test
Kann hier jemand einen Fehler erkennen?
Gruß Manuel
Spontan fällt mir folgendes ein: ich habe - obwohl man es nicht tun sollte - den cronjob für User root eingerichtet, indem ich sudo crontab -e ausgeführt habe und dort die Zeile ergänzt habe.
Was passiert, wenn Ihr den Python Befehl so
python vw_carnet_web.py retrieveCarNetInfo
eingebt? Bekommt ihr dann die Daten auf der Konsole angezeigt?
Wenn ich doch nur Perl könnte. Am liebsten würde ich den Python Ansatz nehmen und in Perl als natives fhem Modul umsetzen, aber das traue ich mir nicht zu.
Hallo Bernd,
leider ergbit
Zitatpython vw_carnet_web.py retrieveCarNetInfo
kein Ausgabe auf der Konsole.
Es dauert 1-2 Sekunden dann erscheint eine neue Eingabezeile.
Gruß Manuel
Könnte der Fehler in der MQTT Konfiguration liegen?
Ich habe MQTT.fx installiert und dort eine Verbindung mit dem Raspberry hergestellt.
Ich kann dort ein Subscribe "/carnet/+" eingeben, auch dort kann ich die Daten nicht sehen...
Es werden aber sehrwohl Daten gesendet und empfangen.
Gruß Manuel
Hast Du in der lib_mqtt Deinen host korrekt eingetragen?
Enter the correct MQTT-broker host and port in the lib_mqtt.py:
MQTT_HOST = "<hostname or IP>"
MQTT_PORT = <port>
Nun könnten wir das Problem haben...
/usr/bin/python: /usr/bin/python: cannot execute binary file
Kommt mir aber seltsam vor, da das Skrit ausgeführt wurde. Ich habe mir im Programmteil "login" einige print Ausgaben eingebaut und damit nachvollzogen dass die Anmeldung bei Carnet erfolgreich durchgeführt wurde.
LG Manuel
Hallo Bernd,
jetzt geht was.
MQTT_HOST = "<hostname or IP>"
MQTT_PORT = <port>
hier hatte ich ein ...
MQTT_HOST = "fhem"
MQTT_PORT = 1883
nun habe ich durch die IP-Adresse eingetragen...
MQTT_HOST = "192.178.168.41"
MQTT_PORT = 1883
Und endlich habe ich viieeeele Readings.
Danke für deine Unterstzützung
Gruß Manuel
Hallo Zusammen,
hat einer mal in Betracht gezogen daraus eine eigene fhem-Erweiterung zu machen? Ähnlich wie z.B. Harmony_Hub? Ich bin mir nicht sicher ob das wegen MQTT möglich ist, wäre aber ein interessanter Ansatz, da es dann einfach zu integrieren wäre....
Viele Grüße
Marek
geht das auch mit Skoda Car Connect?
Ich würde gern zum Beispiel die Standheizung von meinem Kodiaq automatisch über FHEM schalten lassen abhängig von diversen parametern im Haus.
Zitat von: bicmac am 12 Februar 2019, 14:16:28
geht das auch mit Skoda Car Connect?
Das Einschalten der Standheizung wie ich es gemacht habe, dürfte für jede beliebige Marke mit separater Fernbedienung funktionieren!
Lies mal den Thread weiter oben, Stichwort Fischerhechnik...
Hallo,
nach dem Carnet Update bei Volkswagen funktioniert das Modul nicht mehr.
Gruß
Christoph
Das kann ich bestätigen, gibt es schon ein Workaround?
Na zumindest läuft die Diskussion:
Ich hoffe es findet sich bald eine Lösung,....
https://github.com/wez3/volkswagen-carnet-client/issues/16 (https://github.com/wez3/volkswagen-carnet-client/issues/16)
https://github.com/reneboer/python-carnet-client/issues/5 (https://github.com/reneboer/python-carnet-client/issues/5)
VW WE Connect Integration:
Danke an: https://github.com/reneboer/python-carnet-client/pull/7 (https://github.com/reneboer/python-carnet-client/pull/7)
Zu finden als Fork von bgewehr unter :
https://github.com/BAngel87/volkswagen-carnet-client (https://github.com/BAngel87/volkswagen-carnet-client)
Viel Spaß damit,
Grüße Timo 8)
Hat das schon jemand mal mit einem Skoda zum laufen gebracht? Ich glaube dazu müssten ja im python Script die URL getauscht werden oder?
Denn das VW Portal kennt meinen Skoda User nicht.
Ich bekomme momentan folgende Fehlermeldung:
root@raspberry1:/tmp/test# python vw_carnet_web.py retrieveCarNetInfo
Traceback (most recent call last):
File "vw_carnet_web.py", line 350, in <module>
url = CarNetLogin(s,CARNET_USERNAME,CARNET_PASSWORD)
File "vw_carnet_web.py", line 101, in CarNetLogin
csrf = extract_csrf(r)
File "vw_carnet_web.py", line 63, in extract_csrf
return csrf_re.search(r.text).group(1)
AttributeError: 'NoneType' object has no attribute 'group'
Nach Anpassung auf das neue File "we connect" https://github.com/BAngel87/volkswagen-carnet-client (https://github.com/BAngel87/volkswagen-carnet-client)
.. erhalte folgende Rückmeldung von meinem Golf GTE...
Eingetragen habe ich Username und Password sowie die IP für MQTT identisch der zuletzt lauffähigen Installation.
Kann mich jemand unterstützen?
Traceback (most recent call last):
File "vw_carnet_web.py", line 349, in <module>
url = CarNetLogin(s,CARNET_USERNAME,CARNET_PASSWORD)
File "vw_carnet_web.py", line 121, in CarNetLogin
login_action_url = auth_base_url + extract_login_action_url(r)
File "vw_carnet_web.py", line 67, in extract_login_action_url
return login_action_url_re.search(loginhtml).group(1)
AttributeError: 'NoneType' object has no attribute 'group'
Hallo Bernd,
danke für dein Update https://github.com/bgewehr/volkswagen-carnet-client (https://github.com/bgewehr/volkswagen-carnet-client)
Mit crontab -e
habe ich die den zyklischen Aufruf wie folgt angepasst.
*/10 * * * * python /opt/fhem/carnet/volkswagen-carnet-client/we_connect_client.py -u 'geheimer user' -p 'geheimes PSW' -c mqtt
damit läuft es wieder..
:D
Hi, seit gestern ist die Certificate abrage aktiv.
Es funktioniert nichts mehr.
Bekomme folgende Fehlermeldung:
usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:858: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecureRequestWarning)
('Failed to login', 'Failed to get portlet code.')
root@chris-desktop:/opt/CarNet/volkswagen-carnet-client#
Gruß
Christoph
Ich habe im Repo einen switch eingebaut, die Zertifikate auch ungeprüft zu akzeptieren. Damit geht es wieder.
Manchmal wird die VIN nicht korrekt ermittelt. Ich gebe sie inzwischen beim Aufruf mit -v <VIN> mit an, um das zu umgehen.
Danke Bernd ich werde es probieren...
Bitte lies die readme, ich habe inzwischen den Aufruf anders gewählt, um den Code von Reneboer unverändert übernehmen zu können, wenn er wieder etwas verbessert hat.
Bei mir habe ich zusätzlich eine Arteon.py erstellt, die die notwendigen Parameter <User>, <passwort>, <vin> an die my-car.py übergibt, um eben dieses Auto abzufragen.
Dann muss man das nicht so oft in FHEM hinterlegen...
Auch den Aufruf alle 7 Minuten (darunter bekam ich Fehlermeldungen wegen zu häufiger Abfrage) habe ich inzwischen nicht mehr in einem cronjob, sondern in einem At gelöst, dann habe ich alles von fhem aus unter Kontrolle.
defmod carnet_request at +*00:07 {system("python3 /app/carnet/volkswagen-carnet-client/arteon.py -c mqtt")}
Die Verwendung von {system()} hat sich bewährt.
Certverify kann man inzwischen wieder auf true setzen.
Hallo Bernd,
danke dass du deine Updates hier mit uns teilst.
Ich habe versucht deine Änderungen nachzuvollziehen.
So habe ich eine my-Golf_GTE.py erstellt.
Ich habe das so verstanden als ob bei Ausführung die persönlichen Daten in eingelesen werden. Korrekt...?
Bei der direkten Ausführung erhalte ich folgende Rückmeldung - scheinbar ein allgemeiner Fehler welcher mit dem eigentlichen Thema nichts zu tun hat. Kennst du das Problem?
Wo kann man das Certverify auf true stellen?
pi@raspberrypi:~ $ python3 /opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py -c mqtt
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py", line 6, in <module>
from we_connect_client import *
File "/opt/fhem/carnet/volkswagen-carnet-client/we_connect_client.py", line 24, in <module>
import requests
ImportError: No module named 'requests'
LG Manuel
Hi Manuel,
Dir fehlt das Python requests Modul.
pip install requests
oder für Python3
pip3 install requests
Probier das mal...
Die Certverify findest Du in line 24 von we_connect_client.py.
Ich habe mir in der my-car.py die Zugangsdaten fest eingestellt, also so:
...
if __name__ == '__main__':
# Init MQTT connections
MQTT.init()
# parse arguments
[...]
args = parser.parse_args()
CARNET_USERNAME = <meinusername>
CARNET_PASSWORD = <meinpasswort>
CARNET_COMMAND = ''
CARNET_VIN = <meineVIN>
CARNET_SPIN = <meineSPin>
...
Dann muss ich beim Aufruf von my-car.py nur noch den command mit -c übergeben und kann mir mehrere scripte für mehrere Autos anlegen.
Hallo Bernd,
danke für dein direktes Feedback.
Request ist nachinstalliert ...
pi@raspberrypi:~ $ sudo pip3 install requests
Collecting requests
Downloading https://files.pythonhosted.org/packages/1a/70/1935c770cb3be6e3a8b78ced23d7e0f3b187f5cbfab4749523ed65d7c9b1/requests-2.23.0-py2.py3-none-any.whl (58kB)
100% |████████████████████████████████| 61kB 1.1MB/s
Collecting idna<3,>=2.5 (from requests)
Downloading https://files.pythonhosted.org/packages/89/e3/afebe61c546d18fb1709a61bee788254b40e736cff7271c7de5de2dc4128/idna-2.9-py2.py3-none-any.whl (58kB)
100% |████████████████████████████████| 61kB 1.1MB/s
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests)
Downloading https://files.pythonhosted.org/packages/e8/74/6e4f91745020f967d09332bb2b8b9b10090957334692eb88ea4afe91b77f/urllib3-1.25.8-py2.py3-none-any.whl (125kB)
100% |████████████████████████████████| 133kB 1.5MB/s
Collecting certifi>=2017.4.17 (from requests)
Downloading https://files.pythonhosted.org/packages/b9/63/df50cac98ea0d5b006c55a399c3bf1db9da7b5a24de7890bc9cfd5dd9e99/certifi-2019.11.28-py2.py3-none-any.whl (156kB)
100% |████████████████████████████████| 163kB 1.4MB/s
Collecting chardet<4,>=3.0.2 (from requests)
Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Installing collected packages: idna, urllib3, certifi, chardet, requests
Found existing installation: idna 2.2
Not uninstalling idna at /usr/lib/python3/dist-packages, outside environment /usr
Successfully installed certifi-2019.11.28 chardet-3.0.4 idna-2.9 requests-2.23.0 urllib3-1.25.8
scheint aber noch nicht korrekt zu funktionieren ...
pi@raspberrypi:~ $ python3 /opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py -c mqtt Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py", line 32, in <module>
import lib_mqtt as MQTT
File "/opt/fhem/carnet/volkswagen-carnet-client/lib_mqtt.py", line 11, in <module>
import paho.mqtt.client as mqtt
ImportError: No module named 'paho'
Ich bediene mich an dieser Stelle mit den letzen Updates...
Gruß Manuel
(https://github.com/bgewehr/volkswagen-carnet-client%5B/url)
pip install paho-mqtt
oder für Python3:
pip3 install paho-mqtt
EDIT: Ich habe nun auch im Github-Repo die Readme angepasst.
pi@raspberrypi:~ $ sudo pip3 install paho
Collecting paho
Could not find a version that satisfies the requirement paho (from versions: )
No matching distribution found for paho
Sorry, paho-mqtt statt paho!
Danke Bernd
das hätte ich auf selber finden müssen.
Nun kommen keine Fehlermeldungen mehr aber auch keine Aktualisierungen der mqtt
pi@raspberrypi:~ $ python3 /opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py -c mqtt
pi@raspberrypi:~ $
Die einzelnen Kommandos
python3 /opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py -u 'geheume' -p 'sehr geheim' -v 'WVWZZZA.........' -c startClimate
funktionieren ...
Nicht aber
python3 /opt/fhem/carnet/volkswagen-carnet-client/my-Golf_GTE.py -u 'geheume' -p 'sehr geheim' -v 'WVWZZZA.........' -c mqtt
da habe ich jetzt anscheinend etwas verschlimmbessert..
LG Manuel
Falschmeldung! Nach Neustart geht's - danke Bernd!
Hi,
sieht nach super Arbeit aus :)
allerdings wäre es wohl besser anstatt python es als natives fhem Modul neu zu bauen, analog dem Tesla Modul was imho hervorragend funktioniert.
Ich scheue mich etwas nur hierfür extra eine komplette python installation noch zusätzlich auf den Server zu bringen.
Finde ich toll, dass Du das machen möchtest, Tobias.
Sag Bescheid, wenn ich helfen kann!
Moin,
ich habe einen Zertifikatsfehler
/usr/lib/python3/dist-packages/urllib3/connectionpool.py:845: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecureRequestWarning)
Failed to login Failed to get portlet code.
Wo finde ich den Switch zum disablen ?
hi,
ich suche noch immer für eine Möglichkeit meinen Skoda so anzubinden.
Leider klappt das mit dem Weg so nicht.
Hat das schonmal jemand zum laufen gebracht bzw kennt Ihr einen Weg askoda Connect mit FHEM zu koppeln?
Zitat von: bicmac am 03 November 2020, 21:40:41
hi,
ich suche noch immer für eine Möglichkeit meinen Skoda so anzubinden.
Leider klappt das mit dem Weg so nicht.
Hat das schonmal jemand zum laufen gebracht bzw kennt Ihr einen Weg askoda Connect mit FHEM zu koppeln?
Eine Interessante Frage! Bisher habe ich dazu auch noch nichts gefunden. Hat jemand ohne die (suboptimale) App irgend einen Weg gefunden? Ggf sogar mir Stecker im Auto?
Grüße
Gregor
Ich habe mir parallel ein IOBroker installiert und mit FHEM gekoppelt (nutze ich eigentlich für die Visualisierung von FHEM). Im IOBroker gibt es einen VW Adapter der auch Skoda Connect unterstützt.
Zwar ist die Rückmeldung von IOBroker an GHEM nicht ganz so toll, aber es geht. getestet habe ich aber noch nicht das Schalten der Standheizung.
Ein richtiges eigenes FHEM Modul wäre trotzdem besser. leider kann ich das selber nicht realisieren.
Hallo, ich hab mir heute den Connector auch gezogen und im Prinzip funktioniert's.
Ich hab die Nutzerdaten im my-car.py durch die festen Werte ersetzt, um den Aufruf vom FHEM kürzer zu machen.
Aber... ich hab immer eine Fehlermeldung.
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 159, in <module>
mqtt(session, url)
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 51, in mqtt
MQTT.mqttc.publish(MQTT_TOPIC + '/car-details', CarNetPost(s,url_base, '/-/mainnavigation/load-car-details/' + getVin(s, url_base, 0)), qos=0, retain=True)
NameError: name 'getVin' is not defined
Ich habe dann gesehen, dass in der we_connect_client.py eine Funktion enthalten ist, die aber getVIN (in Großbuchstaben) ist.
Dachte mir die Signatur der Funktion passt, also einfach mal VIN groß geschrieben.
Leider ändert sich dann nur die Fehlermeldung - und auch in der Fehlermeldung selbst scheint dann noch ein Codierfehler zu sein:
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client-master/we_connect_client.py", line 442, in getVIN
'vin': estat.get('fullyLoadedVehiclesResponse').get('vehiclesNotFullyLoaded')[index].get('vin')
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 159, in <module>
mqtt(session, url)
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 51, in mqtt
MQTT.mqttc.publish(MQTT_TOPIC + '/car-details', CarNetPost(s,url_base, '/-/mainnavigation/load-car-details/' + getVIN(s, url_base, 0)), qos=0, retain=True)
File "/opt/fhem/carnet/volkswagen-carnet-client-master/we_connect_client.py", line 447, in getVIN
'errorMsg': 'Failed to get VIN for index ' + index
TypeError: can only concatenate str (not "int") to str
Da ich mir nicht weiterhelfen konnte, hab ich aktuell mal die Abkürzung genommen und im my-car.py Zeile 51
das '/-/mainnavigation/load-car-details/' + getVin(s, url_base, 0))
durch '/-/mainnavigation/load-car-details/WVWdefghijk123456' ersetzt. Kein Funktionsaufruf mehr, kein Fehler mehr. ;D ::)
Sieht das Problem mit getVin auch jemand anders ?
Danke, Matthias
Hallo,
ich würde gerne die Ladevorgänge mit der ID Charger Pro Wallbox abrufen. Das geht nicht mit dem python client, oder?
Zitat von: msome am 15 Dezember 2020, 19:45:03
Hallo, ich hab mir heute den Connector auch gezogen und im Prinzip funktioniert's.
Ich hab die Nutzerdaten im my-car.py durch die festen Werte ersetzt, um den Aufruf vom FHEM kürzer zu machen.
Aber... ich hab immer eine Fehlermeldung.
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 159, in <module>
mqtt(session, url)
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 51, in mqtt
MQTT.mqttc.publish(MQTT_TOPIC + '/car-details', CarNetPost(s,url_base, '/-/mainnavigation/load-car-details/' + getVin(s, url_base, 0)), qos=0, retain=True)
NameError: name 'getVin' is not defined
Ich habe dann gesehen, dass in der we_connect_client.py eine Funktion enthalten ist, die aber getVIN (in Großbuchstaben) ist.
Dachte mir die Signatur der Funktion passt, also einfach mal VIN groß geschrieben.
Leider ändert sich dann nur die Fehlermeldung - und auch in der Fehlermeldung selbst scheint dann noch ein Codierfehler zu sein:
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client-master/we_connect_client.py", line 442, in getVIN
'vin': estat.get('fullyLoadedVehiclesResponse').get('vehiclesNotFullyLoaded')[index].get('vin')
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 159, in <module>
mqtt(session, url)
File "/opt/fhem/carnet/volkswagen-carnet-client-master/my-car.py", line 51, in mqtt
MQTT.mqttc.publish(MQTT_TOPIC + '/car-details', CarNetPost(s,url_base, '/-/mainnavigation/load-car-details/' + getVIN(s, url_base, 0)), qos=0, retain=True)
File "/opt/fhem/carnet/volkswagen-carnet-client-master/we_connect_client.py", line 447, in getVIN
'errorMsg': 'Failed to get VIN for index ' + index
TypeError: can only concatenate str (not "int") to str
Da ich mir nicht weiterhelfen konnte, hab ich aktuell mal die Abkürzung genommen und im my-car.py Zeile 51
das '/-/mainnavigation/load-car-details/' + getVin(s, url_base, 0))
durch '/-/mainnavigation/load-car-details/WVWdefghijk123456' ersetzt. Kein Funktionsaufruf mehr, kein Fehler mehr. ;D ::)
Sieht das Problem mit getVin auch jemand anders ?
Danke, Matthias
Ja, diesen Fehler habe ich auch. Ob @bgewehr sich da vielleicht mal anschauen könnte? Ich selbst bin leider nur einfacher Copy&Paste User...
Hallo zusammen,
ich habe gerade eine Info bekommen, dass sich das WeConnect Portal zum 27.4.2021 verabschiedet und durch myVolkswagen ersetzt wird.
https://www.volkswagen.de/de/besitzer-und-nutzer/myvolkswagen.html
Vielleicht/hoffentlich lässt sich die neue Plattform leicht adaptieren...
Das bisherige phython Script hat bei mir bisher sehr gut funktioniert.
Hallo,
scheinbar ist es jetzt wirklich passiert.
Bei mir zeigt das Skript nur noch "Failed to login Failed to get CSRF from landing page." an.
Pünktlich zur Umstellung wie angekündigt.
Schade.
Ich hoffe mal dass es ein Update geben wird, das Cookie csrf, hmac, ... was auch immer Zeug sagt mir gar nix.
Ja,
bei mir auch...
Hallo,
auch ich versuche meinen neuen VW Plug-in in FHEM zu bekommen und bin daher auf dieses Forum gestoßen. Während der Implementierung hat VW das Portal wohl abgeschaltet, so dass man nur noch per App auf die Daten und die Schaltmöglichkeiten kommt.
Im Netz habe ich dieses gefunden:
https://github.com/nightsha-de/npm-vwconnectapi
Ich habe an der Fundstelle aber noch nichts über Fehler gelesen, vielleicht weil dieses Projekt eine andere Zugriffsschicht nutzt???
Vielleicht wäre es auch möglich, dieses NPM, da es ja JS-lastig ist, auch in FHEM zu integrieren???
Hi kurt6908,
ich habe das auch gefunden und gestern abend mehrere Stunden damit zugebracht genau dieses npm-vwconnectapi zum laufen zu bringen.
Hat eine Weile gedauert bis ich rausgefunden hatte dass es nodejs in Version 12 braucht.
Leider aber auch mit begrenztem Erfolg, irgendwie hängt es für ewig in einer Abfrageschleife und wartet auf irgendwas (mit dem Demo-Code als Aufruf).
Da dieses npm-vwconnectapi laut der Git-Seite auf einer ioBroker aufsetzt, hab ich dann sogar den ioBroker und den Connector mal
installiert - und - voila, der Zugang funktioniert, die Daten meines VW-Up werden direkt im ioBroker angezeigt.
Daher sehe ich nach wie vor das npm-vwconnectapi als erfolgversprechenden Weg an.
Der Login an sich hat ja auch im npm-vwconnectapi funktioniert, aber danach hängt es.
Wie man allerdings dann die Daten ins FHEM bringt - darüber hab ich mir noch keine Gedanken gemacht. Notfalls dachte ich mir, bastle ich wieder einen MQTT rein, so wie im vorherigen Skript.
P.S. Ich bin mir nicht sicher ob VW das komplette Portal umgestellt hat, oder ob einfach nur der Login jetzt anders (und auf einem anderen Server) funktioniert ?
Hallo msome,
mein neuer Plug-in wird erst im Juli geliefert, aber dennoch bin ich schon am Anbinden, leider noch ohne eigene Echtdaten ;=)
Dennoch beschäftige ich mich, daher keine Ahnung ob's damit funktioniert:
https://metacpan.org/pod/JavaScript::SpiderMonkey
Idee dahinter: Über Perl einen Javascript-Routine aufrufen .....
Bin über die Seite
https://stackoverflow.com/questions/4767562/is-there-a-way-to-execute-javascript-in-perl
draufgestoßen. Hätte den Charme, dass "direkt" kommuniziert wird und keine weitere Schnittstelle benötigt wird.
Hi, ich hab meinen Versuch aufgegeben die Login-Prozedur von JS ins Python zu übertragen, das ist nicht meine Welt der Programmierung.
Also... "mit Kanonen auf Spatzen schießen". Als meine Lösung hab ich jetzt einfach eine ioBroker Instanz parallel zu FHEM installiert,
darauf den vw-connect Adapter und den fhem Adapter installiert - und es läuft. In weniger als 1 Stunde.
Keine Loginprobleme, alle Daten des Autos werden geladen und schon erfolgreich nach FHEM übertragen.
Lade- und Klimatisierungs-Kommandos funktionierten sofort aus ioBroker raus - wie ich die aus FHEM triggern kann, muss ich noch rausfinden.
Ich brauchte eine schnelle Lösung, denn es gab Kritik von der Regierung - da der Ladestand und die Restreichweite nicht mehr im Haus-Tablet angezeigt wurden. :o :-*
Hi zusammen, zufällig bin ich auf ein Python Projekt gestoßen wo der Login funktioniert.
Es gibt auch eine Anbindung über MQTT, wo auf de Projektseite sogar FHEM als Anwendung erwähnt ist (OK, nur mit einem Wort. Aber immerhin :-) ).
https://github.com/tillsteinbach/WeConnect-mqtt
Ich hab bisher zwar nur die Kommandozeilenversion zum laufen gebracht, denn über MQTT hab ich noch Probleme.
Es sieht aber schon mal gut aus, da ich mit der Kommandozeilenversion den Login überstehe, sowie auch Daten wie Reichweite & Akkustand abfragen kann.
Mit meinem Mosquitto über den FHEM läuft, scheint es noch nicht zu funktionieren.
Vielleicht hat ja jemand Lust, es parallel zu versuchen ?
bfn, Matthias
Sieht bei mir auch soweit gut aus.
Über Docker läuft es bei mir und die Daten kommen über den Broker auch bei FHEM an.
Leider habe ich es noch nicht geschafft über das MQTT_DEVICE mit dem Attribut autoSubscribeReadings alle Daten auszulesen bzw. Readings zu erzeugen.
Es scheint, als ob autoSubscribeReadings nur single-level wildcards '+' unterstützt. Ist laut commandref auch so beschrieben.
Die Topicstruktur ist aber so aufgebaut, dass ich eher multi-level wildcards benötige '#'..
Nachdem ich jetzt zwei Wochen über Skript & Commandline Interface die Werte ausgelesen habe, hab ich jetzt den Umstieg auf Docker+MQTT versucht.
Nachdem ich wie @ReneR1986 bei MQTT_DEVICE nicht weitergekommen bin, bin ich auf MQTT2_CLIENT umgestiegen.
Definiert, auf AutoCreate gestellt - und schon wurde ein Client für weConnect angelegt mit einer Reihe Readings.
Leider werden etliche Readings automatisch mehrfach auf den gleichen Namen gemappt (nur 1 openState statt 6, ...),
aber das lässt sich in der readingList leicht korrigieren indem man am Ende jeder Zeile den Ziel-Reading-Namen anpasst.
Werd morgen mal mit der Erstellung des detaillierten Mappings beginnen um alle MQTT Daten auch in separate Readings zu bekommen.
@ReneR1986, bei mir läuft es jetzt mit Autocreate eines Devices und auch die Readings sind verfügbar.
Ich bin jetzt allerdings auf einen MQTT2_SERVER umgestiegen da meine Mosquitto Verbindung ständig disconnects hatte.
Mit MQTT2_SERVER wollte der Autocreate partout kein Device erstellen.
Nachdem ich dann rausbekommen hatte dass weconnect-mqtt scheinbar per Default keine ClientID oder Prefix übermittelt,
konnte ich über die zusätzlichen Startup-Parameter --prefix tswc --mqttclientid tswcc diese definieren.
Sofort wurde das MQTT2_DEVICE angelegt und die Readings eingetragen.
Falls du auch Docker-compose verwendest, einfach im yml file die zusätzlichen Parameter im ADDITONAL_PARAMETERS angeben.
Bei mir sieht es so aus:
ADDITIONAL_PARAMETERS=--no-capabilities --prefix tswc --mqttclientid tswcc
Das hört sich gut, probiere ich mal aus.
Grundsätzlich hat es bei mir schon funktioniert aber ich habe es eben nicht hinbekommen alle Topics in die Readings per Wildcard zu bekommen.
Werden beim Autocreate vom MQTT2_DEVICE automatisch alle Topics abonniert und in die Readings gepackt?
Er hat automatisch diese hier angelegt...
carCapturedTimestamp 2021-07-31 14:50:14+00:00
carType electric
chargeMode invalid
charging none
chargingState off
climatisationState off
climatisationWithoutExternalPower True
climatization none
coUsers_0_enrollmentStatus NOT_STARTED
coUsers_0_id uuid
coUsers_0_role SECONDARY_USER
coUsers_0_roleReseted False
code
cruisingRangeElectric_km 116
currentSOC_pct 50
enrollmentStatus COMPLETED
group
images {}
info
latitude 47.110000
lockState locked
longitude 08.150000
maxChargeCurrentAC maximum
message
model e-up!
nickname my e-up!
openState closed
overallStatus safe
plugConnectionState disconnected
plugLockState locked
remainingChargingTimeToComplete_min 10
remainingClimatisationTime_min 0
remainingRange_km 116
retry
role PRIMARY_USER
status off
targetTemperature_C 15.5
targetTemperature_K 288.5
totalRange_km 116
type electric
vin WVWirgendeineVIN!
weconnectConnected True
weconnectForceUpdate False
weconnectUpdateInterval_s 300
weconnectUpdated 2021-07-31T21:06:34+00:00
windowHeatingState off
Aber dadurch dass die komplexen Pfade auf das letzte Element eingedampft werden, kollidieren viele Elemente wie z.B. die Türstati.
Das Gute ist, in der ReadingList werden alle automatisch aufgelistet, daher ist eine Korrektur auf das gewünschte Zielreading sehr einfach, z.B.
Autocreated:
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearLeft/openState:.* openState
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearRight/openState:.* openState
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/trunk/openState:.* openState
...
-->
Angepasst:
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearLeft/openState:.* doorOpenStateRL
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearRight/openState:.* doorOpenStateRR
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/trunk/openState:.* doorOpenStateTR
...
Das WeConnect-mqtt ist zum Abrufen der Daten ja ziemlich cool und zuverlässig, aber Steuern kann ich damit gar nichts, oder? Mir ginge es primär um die Klimatisierung, die per App außerordentlich unzuverlässig ist.
Update: ok, es geht mit
attr vw_e_up setList Klimatisierung:Start,Stopp { my %h=('Start'=>'start','Stopp'=>'stop');;qq($DEVICETOPIC/controls/climatization $h{$EVTPART1}) }
Dauert aber sogar noch länger als mit der App bis beim Up angekommen ist. Hängt vielleicht mit dem 300 Sekunden Intervall von WeConnect-mqtt zusammen.
Zitat von: msome am 31 Juli 2021, 23:18:43
Er hat automatisch diese hier angelegt...
carCapturedTimestamp 2021-07-31 14:50:14+00:00
carType electric
chargeMode invalid
charging none
chargingState off
climatisationState off
climatisationWithoutExternalPower True
climatization none
coUsers_0_enrollmentStatus NOT_STARTED
coUsers_0_id uuid
coUsers_0_role SECONDARY_USER
coUsers_0_roleReseted False
code
cruisingRangeElectric_km 116
currentSOC_pct 50
enrollmentStatus COMPLETED
group
images {}
info
latitude 47.110000
lockState locked
longitude 08.150000
maxChargeCurrentAC maximum
message
model e-up!
nickname my e-up!
openState closed
overallStatus safe
plugConnectionState disconnected
plugLockState locked
remainingChargingTimeToComplete_min 10
remainingClimatisationTime_min 0
remainingRange_km 116
retry
role PRIMARY_USER
status off
targetTemperature_C 15.5
targetTemperature_K 288.5
totalRange_km 116
type electric
vin WVWirgendeineVIN!
weconnectConnected True
weconnectForceUpdate False
weconnectUpdateInterval_s 300
weconnectUpdated 2021-07-31T21:06:34+00:00
windowHeatingState off
Aber dadurch dass die komplexen Pfade auf das letzte Element eingedampft werden, kollidieren viele Elemente wie z.B. die Türstati.
Das Gute ist, in der ReadingList werden alle automatisch aufgelistet, daher ist eine Korrektur auf das gewünschte Zielreading sehr einfach, z.B.
Autocreated:
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearLeft/openState:.* openState
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearRight/openState:.* openState
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/trunk/openState:.* openState
...
-->
Angepasst:
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearLeft/openState:.* doorOpenStateRL
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/rearRight/openState:.* doorOpenStateRR
tswcc:tswc/vehicles/WVWirgendeineVIN!/status/accessStatus/doors/trunk/openState:.* doorOpenStateTR
...
Hi, ich habe das gleiche Problem, woher hast du die angepassten "Variablen"?
Ich habe das Problem, das er spordisch einfach keine Werte mehr per MQTT übermittelt und ich dann den Dienst restarten muss.
@SimonHipp
ich versuche mal dich mit zwei Bildern vom Schlauch (vgl. github Diskussion) runterzubringen ;-)
Die Anpassung der Zuordnung habe ich händisch gemacht.
Wenn du im Attribut readingList die einzelnen Zeilen durchgehst sieht man die Kollisionen.
Im MQTT Device legt FHEM bei mir die Readings-Namen als Inhalt des "letztes Segment des MQTT Topics" an,
d.h. blabla-langer-Pfad-openState und
blablablubb-anderer-langer-Pfad-openState
werden beide auf das gleiche Attribut "openState" gemappt.
Ich habe im Bild im Anhang mal versucht Beispiele dafür zu geben wie die Kollision aussieht & im zweiten wie ich sie aufgelöst habe.
Ich habe leider auch keine komplette Auflösung, da ich nur wenige Readings nutze; daher kollidieren immer noch viele davon - ist mir aber egal....
Gruß, Matthias
Zitat von: msome am 07 Januar 2022, 09:21:32
@SimonHipp
ich versuche mal dich mit zwei Bildern vom Schlauch (vgl. github Diskussion) runterzubringen ;-)
Die Anpassung der Zuordnung habe ich händisch gemacht.
Wenn du im Attribut readingList die einzelnen Zeilen durchgehst sieht man die Kollisionen.
Im MQTT Device legt FHEM bei mir die Readings-Namen als Inhalt des "letztes Segment des MQTT Topics" an,
d.h. blabla-langer-Pfad-openState und
blablablubb-anderer-langer-Pfad-openState
werden beide auf das gleiche Attribut "openState" gemappt.
Ich habe im Bild im Anhang mal versucht Beispiele dafür zu geben wie die Kollision aussieht & im zweiten wie ich sie aufgelöst habe.
Ich habe leider auch keine komplette Auflösung, da ich nur wenige Readings nutze; daher kollidieren immer noch viele davon - ist mir aber egal....
Gruß, Matthias
DANKE ich habs jetzt geblickt und wie ich es benötigte angepasst.
Jetzt schauen wir mal ob es heute Nacht und morgen auch noch alles so super läuft.
Grüße
Simon
Hallo zusammen,
ich habe seit heute leider das Problem dass weconnect-mqtt nicht mehr fehlerfrei starten will.
Es kommt immer die Fehlermeldung:
2022-01-28T15:29:31+0100:CRITICAL:weconnect_mqtt_base:There was a problem when communicating with WeConnect. If this problem persists please open a bug report: No credentials form found
Traceback (most recent call last):
File "/opt/fhem/.local/bin/weconnect-mqtt", line 8, in <module>
sys.exit(main())
File "/opt/fhem/.local/lib/python3.9/site-packages/weconnect_mqtt/weconnect_mqtt_base.py", line 252, in main
mqttCLient.disconnect()
File "/opt/fhem/.local/lib/python3.9/site-packages/weconnect_mqtt/weconnect_mqtt_base.py", line 278, in disconnect
disconectPublish.wait_for_publish()
File "/opt/fhem/.local/lib/python3.9/site-packages/paho/mqtt/client.py", line 362, in wait_for_publish
raise RuntimeError('Message publish failed: %s' % (error_string(self.rc)))
RuntimeError: Message publish failed: The client is not currently connected.
Kennt das jemand und hat evtl. eine Lösung parat?
Zitat von: Nighthawk am 28 Januar 2022, 15:40:56
No credentials form found
Ich hab die gleiche Fehlermeldung mit der aktuellen Version:
2022-01-28T16:45:27+0100:CRITICAL:There was a problem when communicating with WeConnect. If this problem persists please open a bug report: No credentials form found
Scheint aber wirklich nur am Login zu liegen - meine seit Tagen immer noch verbundene Instanz bekommt weiter Daten geliefert.
Ich warte erstmal ab. Das VW Portal ist ja immer mal wieder ein paar Stunden offline oder liefert sinnfreie Daten aus.
Wenn es sich die nächsten Tage nicht behebt, bleibt wohl nur, ein Ticket in Github zu öffnen und auf einen Fix zu warten.
Mit weconnect-cli gibt es keine Fehlermeldung, was irgendwie seltsam ist.
Es gab gestern noch ein Update welches den Fehler behebt.
Jup. Allerdings haben sich (irgendwann zwischendurch) die Pfade der Topics geändert.
Ja, den Umstieg hab ich auch noch vor mir, läuft bisher nur auf dem Testsystem.
Es gibt aber jetzt eine FHEM Definition als Template:
https://github.com/tillsteinbach/WeConnect-mqtt/wiki/FHEM-examples
Danke für den Wink, habe gerade upgedatet und es läuft wieder.
Die Regex Definition ist top, danke für den Link, verkürzt meine Definition um das 10fache :-)
Hallo zusammen,
ich bekomme nach einiger Zeit keine Updates mehr. Ich nutze weConnect (und auch FHEM) mit Docker und den MQTT2_SERVER + MQTT2_DEVICE.
Nur wenn ich den weConnect Container neu starte, kommen wieder Daten an.
Auf weConnect Seite konnte ich bisher keine Fehler in den Logs feststellen.
Welche Möglichkeiten habe ich auf FHEM Seite, um zu prüfen, ob hier etwas nicht stimmt?
In den Logs konnte ich bisher hier auch nichts feststellen.
VG
Hast du die neueste Version von weconnect-mqtt und -cli? Hier gab es Änderungen bezüglich der Authentifizierung...
Ja, ist die latest