abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 


REST API Zugriff mit ESP32

tobo123
Experienced Homie

Hallo zusammen,

 

ich versuche über einen ESP32 Mikrocontroller auf den BSH Controller II über die REST API zuzugreifen. Ich möchte gerne Zustände auslesen, um bei meiner Smarten Anzeige auf eine Ledvance-Platine verzichten zu können. Den ESP32 programmiere ich über die Arduino IDE.

 

Bisher habe ich folgendes erreicht:

- Abfrage der Public Information, Anlegen eines neuen Client und anschließende Abfrage z.B. des room arrays über Postman.

- Ich kann über den ESP32 über Port 8446 per GET die Public Information auslesen.

- Ich kann über den ESP32 über Port 8443 per POST einen neuen Client anlegen. Dieser erscheint auch in der Smart Home APP unter "Weitere Mobilgeräte".

 

So weit, so gut. Was jetzt aber nicht geht, ist anschließend über Port 8444 per GET z.B. das room array abzufragen. Die Verbindung kommt hier nicht zustande. Laut Postman muss ich doch im Header außer dem Host nichts mit senden, oder?

 

Ich habe schon viel rumprobiert und bin jetzt etwas ratlos. Hat jemand eine Idee, woran es liegen könnte?

 

VG tobo

Seit 2024 privater BSH Nutzer. SHC II + 26 Geräte + 33 Automationen + 14 Zustände.
Samsung S22+, Samsung Tab S9 FE, ESP8266-basierte Geräte
8 ANTWORTEN 8

tobo123
Experienced Homie

Ein Update von mir: ich habe alles mögliche probiert, um die REST API auf meinem ESP32 zum laufen zubekommen, ohne Erfolg. Ich bin jetzt auf ein ESP8266 umgestiegen und hier geht es 🙂

 

Ich kann den ESP als Client anmelden und Geräte und die Zustände abfragen. Der Hammer! Das eröffnet echt viele Möglichkeiten. Ich werde als nächstes mein smarte Anzeige auf die REST API umstellen.

 

 VG tobo

Seit 2024 privater BSH Nutzer. SHC II + 26 Geräte + 33 Automationen + 14 Zustände.
Samsung S22+, Samsung Tab S9 FE, ESP8266-basierte Geräte

ilja-stas
Apprentice Homie

Hi @tobo123,

 

könntest du ein Beispiel Code hier reinposten? Ich bekomme ständig SSL Certificat Issues. Auch wenn ich requests.get(..., verify=False) mache (mit Python).

 

Danke

Ilja

ilja-stas
Apprentice Homie
import requests
import base64
import urllib3

# Suppress the InsecureRequestWarning related to verify=False
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# Variables (replace with actual values)
shc_api = "https://192.168.0.10:8444"  # Replace with your actual SHC API URL
api_version = "3.13"  # Replace with the actual API version you're using
system_password_base64 = base64.b64encode(b'testtest').decode('utf-8')  # Replace with your password

# Endpoint for devices
url = f"{shc_api}/smarthome/devices"  # Replace with the actual devices endpoint

# Path to client certificate and key files (replace with actual paths)
client_cert = ('/home/ilja/python-cert.pem', '/home/ilja/python-key.pem')  # Update these paths

# Headers
headers = {
    'Content-Type': 'application/json',
    'User-Agent': 'PostmanRuntime/7.42.0',
    'Accept': '*/*',
    'Accept-Encoding': 'gzip, deflate, br',
    'Connection': 'keep-alive',
    'Systempassword': system_password_base64,
    'api-version': api_version,
    'Host': '192.168.0.10:8444',
}

# No payload needed for GET request to /smarthome/devices

# Make the GET request with client certificate
response = requests.get(url, headers=headers, cert=client_cert, verify=False, timeout=120)

# Print the response
print(f"Status Code: {response.status_code}")
print(f"Response Body: {response.text}")

ilja-stas
Apprentice Homie

That code is working

Sehr gut, wenn es damit geht. Ich programmiere mit C++ / Arduino, weiß daher nicht, ob dir mein Code nützt. Den kannst du dir hier anschauen: https://github.com/tobo-123/smart-home-display

 

Den Header kannst du kürzen. Das Passwort brauchst du z.B. nicht mitsenden.

Seit 2024 privater BSH Nutzer. SHC II + 26 Geräte + 33 Automationen + 14 Zustände.
Samsung S22+, Samsung Tab S9 FE, ESP8266-basierte Geräte

Hi,

erstmal vielen Dank für die Bereitstellung des Quelltextes und der Druckdateien!

Damit hast du mir sehr viel Arbeit erspart, da ich genau das benötige, was du entwickelt hast.

Ich habe bereits alles nach der Materialliste bestellt und das Gehäuse in den Druck gegeben.

Zwei Fragen hätte ich dazu:

du nutzt bei den Zuständen Fenster auf/zu und Alarm an/aus.

Wie genau hast du das in den Automationen gelöst? 

Den Zustand des Alarmsystems kann man zwar als Bedingung aber nicht als Auslöser nutzen?

Ich habe mir die API angeschaut und hätte erst gedacht, dass du das z.B. über 

/intrusion/states/system abfragen würdest. 

 

Sind die zusätzlichen Erhebungen im Front-Gehäuse eventuell dafür gedacht, einen Batteriebetrieb zu ermöglichen?

 

 

viele Grüße  

Christian

tobo123
Experienced Homie

Hey, cool dass du meine Anzeige nachbauen willst.

 

Für Fenster auf habe ich jeweils eine Automation, die den Zustand "Fenster auf" aktiviert bzw. deaktiviert. Fenster auf Automation sieht so aus: WENN Fenster X geöffnet wird oder Fenster Y geöffnet wird.... DANN Zustand Fester auf aktivieren.

 

Fenster zu Automation: WENN Fenster X geschlossen wird oder Fernster Y geschlossen wird oder.... UND Fenster X geschlossen ist und Fenster Y geschlossen ist und... DANN Zustand Fenster offen deaktiveren.

 

Das Alarmsystem aktiviere ich durch eine Automation (entweder manuell oder mit einem Universalschalter II) , die dann gleichzeitig für 30s den Zustand "Alarmerinnerung" aktiviert. Die 30s entsprechen der Aktivierungszeit im Alarmsystem. Ebenso geht der Zustand Alarmerinnerung an, wenn das Alarmsystem aktiviert ist und ich nachhause komme (Türkontakt an der Haustür), bis ich das Alarmsystem durch eine Automation ausschalte.

 

Klar könnte man den Zustand des Alarmsystems auch direkt aus der API abfragen. Ich wollte aber als Schnittstelle zwischen meiner Anzeige und der API nur die Zustände nutzen. Das macht das Programm einfacher.

 

Die zusätzlichen Erhebungen im Frontgehäuse sind noch Überbleibsel aus der Zeit, wo ich neben dem ESP noch eine Ledvance-Platine verbaut hatte. Die sind jetzt also ohne Funktion. Mit Batterie würde die Anzeige leider nicht lange laufen, dafür braucht der ESP und die LED zuviel Strom.

Seit 2024 privater BSH Nutzer. SHC II + 26 Geräte + 33 Automationen + 14 Zustände.
Samsung S22+, Samsung Tab S9 FE, ESP8266-basierte Geräte

Danke für die schnelle und ausführliche Rückmeldung!

Ich hatte schon befürchtet, dass der Batteriebetrieb schwierig sein würde.

Muss dann mal schauen, wie ich dann Strom in die Ecke bekomme, wo deine Anzeige hinkommen soll.

 

Ich erzähle mal kurz, wofür ich die Anzeige hauptsächlich benötige:

Anfangs haben wir über die Handy App scharf und unscharf geschaltet. Das hatte leider zur Folge, dass oftmals gar nicht scharf geschaltet wurde oder kurz nach dem öffnen der Eingangstür der Alarm ausgelöst wurde.

Ich dachte mir, die praktikabelste Lösung wäre die Einbindung des Smartlocks von Yale.

Was ich damals noch nicht wusste: die Übermittlung der Schließzustände läuft über die Cloud und nicht über Lan oder ZigBee. Hin und wieder kommt es dadurch zu einer Verzögerung von 30 - 90 Sekunden (manchmal sogar noch mehr), bis der SHC mitbekommt, dass die Tür ordentlich geöffnet wurde. Dies führte immer wieder zu Fehlalarmen, da ich eine Alarm Verzögerung von 30 Sekunden und dann später 60 Sekunden eingestellt habe.

 

Es ist nervig immer erst aufs Handy zu schauen, ob wirklich unscharf geschaltet wurde, daher wäre ein kurzer Blick auf die Anzeige wesentlich angenehmer und auch verlässlicher, da ein rotes Blinken der LED direkt ins Auge sticht.

Daher muss ich den tatsächlichen Zustand der Alarmanlage abfragen können.

 




Rechtswidrigen Inhalt melden