Beiträge von DasBasti

    Da interessiert mich aber als Ingenieur der technische Aspekt dahinter. Das würde bedeuten, der PUK muss in der Nähe des Fahrzeuges sein um nicht schnell leer zu gehen. Oder mit wem soll der PUK denn sonst noch kommunizieren müssen um nicht
    schnell leer zu gehen ? Kommunikation kostet in der Regel mehr Strom als keine Kommunikation, also irgendwie ein Widerspruch.

    So eine RFID Abschirmtasche ist im Grunde ein Faradayscher Käfig. NFC funktioniert mit aktivem Erregerfeld und Schwingkreis. Zur Kommunikation wird gemessen, wie stark das Feld gedämpft wird. Wenn der PUK in der Tasche das Feld erzeugt, können die Drähte in der Abschirmtasche die komplette Energie aufnehmen, was den PUK dazu veranlassen könnte noch mehr Energie in die Felder zu stecken und somit die Dämpfung ermitteln zu können. Aber das ist reine Spekulation es kommt immer drauf an, wie genau das im Gerät umgesetzt ist. Aber es könnte den Effekt erklären :)

    Habe gerade nochmal nachgeschaut jetzt zeigt die App 14,275 V an, das passt schon ehr.

    Komisch :/

    Der Smart liefert ab und zu mal 5V als Wert zurück, das ist mir in der Homeassistant Komponente auch schon aufgefallen. Das ist der Wert, der von der WebAPI zurückgeliefert. Da können die Anzeigeapps nichts dran ändern.

    For calculating charging power I used the battery current not thecharge port current. So the difference is charging loss, I suppose.


    The proconditioning climate entity throws an error but it starts precon on my smart. Does it work for yours as well?


    ---


    Die Ladeleistung wird aus dem Strom in die Batterie errechnet, Differenzen zum Strom am Ladeanschluss ist Ladeverlustleistung, so habe ich das zumindest interpretiert.


    Die Vorkonditionierung über die clima Entity gibt bei mir einen Fehler zurück, startet aber die Vorkonditionierung. Kannst du das auch bestätigen?

    So wie ich das sehe, werden derzeit in Home Assistant ausschließlich Sensor-Entitäten bereitgestellt, die nur eine Abfrage von Werten zulassen. Selbst eine DeviceTracker-Entität habe ich nicht.

    Zum Verändern von Fahrzeugeinstellungen, müssten Button-, Switch-, Climate-, Lock- oder Cover-Entitäten bereitgestellt werden. Das ist zumindest bei mir nicht der Fall. Ich konnte darüber hinaus auch keine Dienste erkennen, die von der Integration bereitgestellt werden. Somit gehe ich davon aus, dass man mit HA aktuell nur Daten abfragen kann, selbst wenn die zugrundeliegende Bibliothek mehr Funktionen anbieten sollte, scheinen die aktuell für HA noch nicht implementiert zu sein.

    Es sollten eigentlich seit Version 0.3.0 sowohl die Vorklimatisierung als auch der DeviceTracker als Entität zur Verfügung stehen. Aktuell habe ich nicht sonderlich viel Zeit daran zu entwickeln, aber ich habe mit Sitz-/ und Lenkradheizung Ansteuerung begonnen.

    Ich habe die eine neue Version Homeassistant der Integration veröffentlicht. Bitte beachtet, dass ihr das Fahrzeug neu anlegen müsst, es hat sich einiges im Unterbau geändert. Ich hoffe das jetzt Leute mit mehreren Fahrzeugen auch mehrere Fahrzeuge anlegen können, aber ich kann das leider nicht vernünftig testen, hab nämlich nur eins ;)

    Für alle, die HA im Docker betreiben, ich habe eine Version 0.1.1 für die Integration erstellt. Diese sollte das Problem lösen. Oder auf eine neuere Version von HA gehen, das hat bei Diddeler geholfen.

    Grund ist eine http Bibliothek, die von HA mitgebracht wird und die Weiterleitung im Login Prozess nicht korrekt durchführt.

    Ich bin gerade an der Version 0.2.0 der Integration, da will ich die entity IDs passender gestalten.

    Wenn bei der Inbetriebnahme der Integration der Login mit der Fehlermeldung "auth" scheitert und im HA Protokoll etwas von "Could not get context from login page" steht, dann schreibt mir doch bitte. Soll ja für alle funktionieren 😉