Neueste Beiträge

Seiten1 2 3 ... 10
#1
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 30 Mai 2026, 00:47:34
Hallo miteinander,

nach den diversen Fixes der letzten Wochen geht es nun weiter mit der Weiterentwicklung des neuronalen Netzes
mit dem Ziel der BEV Integration.

Dafür ist das Netz deutlich erweitert und hat ein "Gedächtnis" bekommen bzw. ausgebaut.
Über die sogenannten Lag-Features lernt das Netz:

* den Verbrauch vor 1 Stunde (Trägheit)
* den Verbrauch vor 2 Stunden (Trägheit)
* den Verbrauch gestern zur gleichen Stunde (Tagesmuster)
* den Verbrauch letzte Woche zum gleichen Tag und Stunde (Wochenmuster)

Das Modell erkennt dadurch:

* Gewohnheiten
* Tagesrhythmen
* Wochenrhythmen
* Trends (steigend/fallend)

Es waren bereits Lags eingebaut und wurden nochmal deutlich erweitert.
Das Netz ist nun aber auch empfindlicher bezüglich nicht erkennbarer Zusammenhänge, also wenn das Netz nicht erkennen kann weshalb es einen höheren oder tieferen Verbrauch gibt, denn unsere Haushalte sind stochastisch.
Ein normaler Haushalt ist stochastisch, weil der Verbrauch nicht deterministisch, sondern zufallsgetrieben,
unregelmäßig und nur teilweise vorhersagbar ist.
Unsere Tätigkeiten sind weitgehend unvohersehbar denn es ist nicht bestimmt wann jemand den Föhn einschaltet, den Herd benutzt, gebügelt, die Wama/der Trockner genutzt wird oder jemand duscht und dadurch der WW-Speicher nachgeheizt werden muß.

Das "Rauschen" ist groß und deshalb wurden Lag-Features, Rolling-Features und Volatilitäts-Signale ausgebaut.
Das Bewertungssystem musste angepasst werden, denn wir erreichen in einem stochastischen Haushalt nicht mehr so hohe mathematische Slope oder R2 Werte wie vorher, aber nicht desto trotz sehr gute bis ausgezeichnete Ergebnisse.

Strukturierte Haushalte, also wo (bestimmende) Verbraucher aus Sicht der KI besser vorhersagbare Energien benötigen wie z.B.
WP und Klimaanlagen (Temperatur und Saison getrieben), Poolheizungen (PV & Saison), BEV (abhängig von Batterieladung, Gewohnheiten)
habe vermutlich einen Vorteil von der aktualisierten Logik.

Kurzum, es befindet sich eine neue Version 2.7.0 im contrib.
Aber ACHTUNG! Diese Version ist erstmal nur geeignet für User die gern etwas mit dem neuronalen Netz experimentieren wollen und
Erfahrung mit den neuen Möglichkeiten und Verhalten sammeln möchten.
Es ist auf jeden Fall ein neues Training nötig und wahrscheinlich/evtl. auch mit unkonventionell veränderten Einstellungen.
Aber die Ergebnisse können sich sehen lassen. Der Retrain-Status bekommt auch keine rote Ampel mehr, denn es ist kein Fehler, sondern
ist einfach nur der Hinweis, dass das System gern einen weiteren Trainingslaug gemacht hätte weil die Zielgüte noch nicht erreicht ist.
Dieser Status hat nun eine blaue Ampel, also mehr "neutral".

Also wer mag, kann sich die nächste Zeit ein wenig mit der Weiterentwicklung beschäftigen. Ich mache erstmal ein bisschen Urlaub, schaue aber sicherlich ab und an mal hier rein. ;)
Später wird auf dieser Version bezüglich BEV Integration aufgebaut.

LG,
Heiko
#2
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von tostmann - 29 Mai 2026, 23:12:08
Kleiner Dank an dieser Stelle an fred_feuerstein: Dein ausführliches Testen und die seriellen Logs — gerade der Discovery-Crash-Dump — haben in den letzten Tagen gleich mehrere Macken aufgedeckt, die dadurch schnell gefixt werden konnten (Discovery-Stack, device-seitige Streams, Speaker-Sortierung). Sehr wertvolles Feedback!

Und weil's gerade passt (kleiner Cross-Post, hihi): SixBack hat's auf Hackaday geschafft — Bring Back Your Bose With An ESP32.
#3
Multimedia / Aw: [Neues Modul] BOSE SoundTo...
Letzter Beitrag von fred_feuerstein - 29 Mai 2026, 22:26:04
wegen der nicht funktionierenden Speak-Funktion.

Denke hier im Modul erfolgt das mit der Sprachausgabe:
Code Auswählen
sub BOSEST_speak($$$$$) {
    my ($hash, $text, $volume, $lang, $stopAfterSpeak) = @_;

    $lang = AttrVal($hash->{NAME}, "ttsLanguage", "en") if($lang eq "");
    $volume = AttrVal($hash->{NAME}, "ttsVolume", ReadingsVal($hash->{NAME}, "volume", 20)) if($volume eq "");

    if(length($text) < 100) {
       my $uri_text = uri_escape($text);
       my $translateUrl = "http://translate.google.com/translate_tts?ie=UTF-8&tl=$lang&client=tw-ob&q=$uri_text";
       $translateUrl =~ s/\&/\&amp\;/g;

       if(substr($volume, 0, 1) eq "+" or
          substr($volume, 0, 1) eq "-") {
           $volume = ReadingsVal($hash->{NAME}, "volume", 0) + $volume;
       }

       my $postXml = '<play_info><app_key>Ml7YGAI9JWjFhU7D348e86JPXtisddBa</app_key><url>'.$translateUrl.'</url><service>'.$text.'</service><volume>'.$volume.'</volume></play_info>';
       if(BOSEST_HTTPPOST($hash, '/speaker', $postXml)) {
       }

       if(defined($stopAfterSpeak) && $stopAfterSpeak eq "1") {
           $hash->{helper}{stateCheck}{enabled} = 1;
           #after play the speaker changes contentItemItemName
           $hash->{helper}{stateCheck}{actionContentItemItemName} = "";
           $hash->{helper}{stateCheck}{function} = \&BOSEST_off;
       }

       return undef;
    }
   
   
    my $ttsDir = AttrVal($hash->{NAME}, "ttsDirectory", "");
   
    my $sox = qx(which sox);
    chomp $sox;
    if(!-x $sox) {
        BOSEST_playGoogleTTS($hash, $ttsDir, $BOSEST_READ_CMDREF_TEXT, $volume, $BOSEST_READ_CMDREF_LANG, $stopAfterSpeak);
        return undef;
    }
   
    #download file and play
    BOSEST_playGoogleTTS($hash, $ttsDir, $text, $volume, $lang, $stopAfterSpeak);
   
    return undef;
}
Da ist ja auch ein app_key enthalten. Evtl. hat es damit was zu tun? Abgelaufen?

Hat da jemand mehr Ahnung von als ich?
#4
FHEM Development / Aw: fheminfo send: timeout bei...
Letzter Beitrag von Sidey - 29 Mai 2026, 22:17:02
Du hast sehr wahrscheinlich ein IP V6 Problem.

Könnte das Problem außerhalb des Containers liegen? Vielleicht eine Firewall?

Grüße Sidey
#5
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von fred_feuerstein - 29 Mai 2026, 21:50:09
Habe gerade noch die Version 0.8.6 installiert.

Neu: die bose Devices können sortiert werden (per drag/drop in der Übersicht)

Klasse!

Vielen Dank.
#6
FHEM Development / Aw: fheminfo send: timeout bei...
Letzter Beitrag von betateilchen - 29 Mai 2026, 21:11:50
Zitat von: betateilchen am 29 Mai 2026, 21:07:44
  • Die nicht funktionierende Instanz hat das globale Attribut useInet6 gesetzt, die andere Instanz nicht.

Wenn ich das Attribut entferne, funktioniert das Senden auch auf der Produktivinstanz:

Code Auswählen
2026.05.29 21:09:31 4: fheminfo send (nonblocking): {...}
2026.05.29 21:09:31 4: IP: fhem.de -> 188.40.131.57
2026.05.29 21:09:32 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.29 21:09:32 4: fheminfo send: Server RESPONSE: ==> ok

Dann funktionieren allerdings viele andere Dinge nicht mehr...
#7
FHEM Development / Aw: fheminfo send: timeout bei...
Letzter Beitrag von betateilchen - 29 Mai 2026, 21:07:44
  • Beide Instanzen laufen als Proxmox Container.
  • Die nicht funktionierende Instanz hat das globale Attribut useInet6 gesetzt, die andere Instanz nicht.
  • Die "nicht funktionierende" Instanz ist meine Produktivinstanz, auf der ansonsten netzwerktechnisch alle Verbindungen funktionieren, nur das fheminfo send klappt nicht.

Funktionierende Instanz:

Code Auswählen
udo@fhem-sip:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:ba:0b:06 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.123.219/24 brd 192.168.123.255 scope global dynamic eth0
       valid_lft 79650sec preferred_lft 79650sec
    inet6 fddc:7b04:1a06:0:be24:11ff:feba:b06/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 7200sec preferred_lft 3600sec
    inet6 2002:5510:9940:0:be24:11ff:feba:b06/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 7199sec preferred_lft 3599sec
    inet6 fe80::be24:11ff:feba:b06/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever

Nicht funktionierende Instanz:

Code Auswählen
udo@fhem:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether bc:24:11:46:b6:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.123.111/24 brd 192.168.123.255 scope global dynamic eth0
       valid_lft 75883sec preferred_lft 75883sec
    inet6 fddc:7b04:1a06:0:be24:11ff:fe46:b6a4/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 6643sec preferred_lft 3043sec
    inet6 2002:5510:9940:0:be24:11ff:fe46:b6a4/64 scope global dynamic mngtmpaddr proto kernel_ra
       valid_lft 6642sec preferred_lft 3042sec
    inet6 fe80::be24:11ff:fe46:b6a4/64 scope link proto kernel_ll
       valid_lft forever preferred_lft forever
#8
FHEM Development / Aw: fheminfo send: timeout bei...
Letzter Beitrag von Sidey - 29 Mai 2026, 20:56:50
Wie ist denn Instanz 1  und wie Instanz 2 an dein Netzwerk angebunden?
Haben die Instanzen ggf. mehrere Netzwerkadapter?

Grüße Sidey
#9
FHEM Development / fheminfo send: timeout beim Se...
Letzter Beitrag von betateilchen - 29 Mai 2026, 20:45:59
Code Auswählen
2026.05.29 20:39:17 4: fheminfo send (nonblocking): {...}
2026.05.29 20:39:17 4: IP: fhem.de -> [2a01:4f8:221:1b5a::b2]
2026.05.29 20:39:21 1: fheminfo send: Server ERROR: connect to https://fhem.de:443 timed out

Das Problem tritt nur bei einer meiner drei FHEM-Instanzen auf.
Eine der beiden anderen Instanzen läuft hier im gleichen Netzwerk und funktioniert, ein generelles Netzwerkproblem schließe ich deshalb aus.

Hat jemand einen Tipp, wie ich das Problem weiter eingrenzen kann? Bauchgefühl sagt mir, ich könnte mal wieder ein IPv6 Problem haben. Denn die andere Instanz, die hier im Netzwerk funktioniert, verwendet eine IPv4 Adresse von fhem.de

Code Auswählen
2026.05.29 16:18:30.998 4: fheminfo send (nonblocking): {...}
2026.05.29 16:18:30.999 4: IP: fhem.de -> 188.40.131.57
2026.05.29 16:18:31.510 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2026.05.29 16:18:31.510 4: fheminfo send: Server RESPONSE: ==> ok
#10
Sonstiges / Aw: Neu: 55_MiniSIP.pm - ein S...
Letzter Beitrag von betateilchen - 29 Mai 2026, 20:07:16
Zitat von: betateilchen am 27 Mai 2026, 21:07:49Primäre Aufgabenstellung:

Wenn es eine primäre Aufgabenstellung gibt, sollte es ja mindestens noch ein weiteres Einsatzszenario geben.
Ja, tut es auch.

Auf meinem Schreibtisch steht seit kurzem ein Telefon mit Erweiterungsmodul, bei dem sich die meisten Tasten frei belegen lassen.

Du darfst diesen Dateianhang nicht ansehen.

Alleine das Erweiterungsmodul stellt 20 Tasten auf drei Ebenen (insgesamt 60) zur Verfügung. Und von diesen Erweiterungsmodulen kann man bis zu drei Stück installieren...
Jede der Tasten besitzt eine LED, die rot grün oder orange leuchten können. Und das Ganze dann auch noch als Dauerlicht, schnell blinkend oder langsam blinkend. Wie man das eben bei professionellen Telefonanlagen kennt, um Besetztanzeigen, geparkte oder gehaltene Anrufe zu signalisieren.

Und das wollte ich nun auch in FHEM für die Anzeige von diversen Geräte-Status verwenden.
Um das zu erreichen, muss an das Telefon eine SIP Message geschickt werden, deren body folgenden Inhalt hat:

Code Auswählen
my $body = <<"BODY";
k=$key
a=message
c=$command
o=$color
l=$label
n=**55
BODY


$key      = die Nummer der Funktionstaste
$label    = die Beschriftung, die an der Taste angezeigt wird
$color    = die Farbe, in der die LED leuchten soll
$command  = der Befehl, der die LED schaltet (on/off/park/...)
a=message : legt fest, ob sich die Taste beim Drücken mittels INVITE oder MESSAGE meldet
n=**55    : Die "Nummer" die von der Taste gewählt wird, wenn sie INVITE benutzt


Bei den Tasten habe ich mich für den Typ MESSAGE entschieden, dann gibt es keine zu wählende Nummer, sondern es kommt im body des vom Telefon geschickten SIP-Paketes eine Zeile "k=48" an, wenn die Taste 48 gedrückt wurde.


Dann habe ich mir eine 99_snomUtils.pm angelegt, dort ist ein FHEM Befehl "snomled" definiert.
Nun kann ich mit

Code Auswählen
snomled snom 48 on orange Button 48
dafür sorgen, dass die Taste 48 mit "Button 48" beschriftet wird und orange leuchtet.

Prinzipiell geht es dann so weiter:

  • alle Geräte, für die eine Statusanzeige auf dem Telefon gewünscht ist, sind in einer structure enthalten
  • diese structure löst immer dann, wenn sich an einem der devices ein status ändert, ein event aus
  • auf dieses event triggert ein notify und ruft eine Funktion in der 99_snomUtils.pm auf
  • in dieser Funktion wird ermittelt, welches device eine Änderung gemeldet hat und welche Statusanzeige deshalb aktualisiert werden muss

Funktioniert jetzt seit einer Woche recht problemlos.

Natürlich gibt es auch den anderen Weg: Mittels einer Taste auf dem Telefon eine Lampe schalten oder ein Rollo auf- oder zuzufahren.

Das eigentlich trickreiche an der Sache war die Kombination der beiden Tastennutzungsarten.
Das reine Schalten per Tastendruck gelingt quasi out-of-the-box, ich kann die Taste auch als "Action-URL" konfigurieren, dann wird einfach ein HTTP-GET ausgelöst, das z.B. in FHEM eine HTTPAPI aufruft. Dann lässt sich aber keine Rückmeldung in Form einer LED am Telefon geben.

Die LED Anzeige funktioniert nur beim Tastentyp "Button" - der kann aber keinen HTTP request auslösen...
Seiten1 2 3 ... 10