Autoerkennung neues Modul 36_Shelly.pm Version "4.04d"

Begonnen von RalfRog, 06 Mai 2023, 00:31:25

Vorheriges Thema - Nächstes Thema

RalfRog

Hallo Starkstrombastler
Hier ist er, der kurze Ausstieg aus dem Beitrag #363 https://forum.fhem.de/index.php?msg=1274939 im Suppport-Thread (geht um #353 los).

Bei mir funktioniert im Gegensatz zu Starkstrombastler die Autoerkennung vom Shelly Plug S nicht.
Im Prinzip macht das diese Sub "sub Shelly_get_model" ab Zeile 450 und für Gen1 ab Zeile 458 mit "HttpUtils_NonblockingGet" geholt.
Die Datenstuktur zum Auslesen des Modells wird ab Zeile 486 mit "$jhash = eval{ $json->decode( $data )" erstellt.
486    $json = JSON->new->utf8;
487    $jhash = eval{ $json->decode( $data ) };
488    if( !$jhash ){
489      # this is intentionally no error
490      Log3 $name,5,"[Shelly_get_model] has invalid JSON data for device $name";
491      readingsSingleUpdate($hash,"state","Error",1);
492      return;
493    }

Da der Shelly Plug S nicht erkannt wurde hab ich zum Testen ergänzt:
486     $json = JSON->new->utf8->relaxed;
487 Debug $json;
488 Debug $data;
489 Log3 $name,3,"Dumper Data von settings: \n" . Dumper ($data);
490
491     $jhash = eval{ $json->decode( $data ) };
492 Debug $jhash;
493 Log3 $name,3,"Dumper jhash nach decode: \n" . Dumper ($jhash);
494     if( !$jhash ){
495       # this is intentionally no error
496       Log3 $name,5,"[Shelly_get_model] has invalid JSON data for device $name";
497       readingsSingleUpdate($hash,"state","Error",1);
498       return;
499     }

Zunächst mal die Werte der Variablen (mit Debug in Log geschrieben):
** Vom Plug **
2023.05.05 17:53:00.536 1: DEBUG>JSON=SCALAR(0x37fe2d0)
2023.05.05 17:53:00.540 1: DEBUG>{"device":{"type":"SHPLG-S",...
2023.05.05 17:53:00.549 1: DEBUG>

** Vom 1PM **
2023.05.05 22:21:07.164 1: DEBUG>JSON=SCALAR(0x3904c28)
2023.05.05 22:21:07.167 1: DEBUG>{"device":{"type":"SHSW-PM","...
2023.05.05 22:21:07.180 1: DEBUG>HASH(0x390e888)

Für den nicht erkannten Plug wird für "$jhash" keine Hash-Referenz geschrieben - für den 1PM HASH(0x390e888).
Der JSON String in der Variablen $data per Debug in Log geschrieben sieht für den Plug S und den 1PM eigentlich (fürs Auge, {"device":{"type":") gut aus.

Daher hatte ich in einem zweiten Schritt noch zusätzlich den Dumper eingebaut. Der liefert:
** Vom Plug **
2023.05.05 22:15:55.688 3: Dumper jhash nach decode:
$VAR1 = undef;

** Vom 1PM **
2023.05.05 22:21:07.198 3: Dumper jhash nach decode:
$VAR1 = {
          'tz_dst_auto' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
          'ext_switch' => {
                            '0' => {
                                     'relay_num' => -1
                                   }
                          },
          'mqtt' => {
                      'clean_session' => $VAR1->{'tz_dst_auto'},
                      'server' => '192.168.33.3:1883',
                      'reconnect_timeout_max' => '60',
                      'max_qos' => 0,
                      'user' => '',
                      'update_period' => 30,
                      'reconnect_timeout_min' => '2',
                      'enable' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
                      'id' => 'shelly1pm-E868E7868614',
                      'keep_alive' => 60,
                      'retain' => $VAR1->{'mqtt'}{'enable'}
                    },


Wenn man da genau hinschaut sieht die Datenstruktur des Hash doch an einigen Stellen komisch aus.
Immer dort (schon gleich am Anfang die 'tz_dst_auto') wo ein Boolean mit "true,false" steht.


Rumgoogeln nach den Funktionen von use:JSON  (JSON->new->utf8;) brachte mich auf den Parameter relaxed (JSON->new->utf8->relaxed) - Nebenwirkungen keine Ahnung.

Immerhin klappt Autocreate nun aber leider sieht damit das Ergebnis für dem 1PM auch noch nicht gut/besser aus.
2023.05.06 00:27:30.343 3: Dumper jhash nach decode:
$VAR1 = {
          'max_power' => 500,
          'build_info' => {
                            'build_timestamp' => '2021-03-23T10:59:28Z',
                            'build_id' => '20210323-105928/v1.10.1-gf276b51',
                            'build_version' => '1.0'
                          },
          'allow_cross_origin' => $VAR1->{'actions'}{'active'},
          'led_status_disable' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
          'fw' => '20210323-105928/v1.10.1-gf276b51',

Finale Frage also - wieso sehen die Daten so verkorkst aus bzw. kommt ein leerer Wert zurück?
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

RalfRog

#1
Ergänzung für den Shelly 3EM.
Auch da sehen die von "eval{ $json->decode($data)}" erzeugten und durch Dumper ausgegebenen Daten etwas komisch aus, da wo eigentlich Boolean-Werte stehen sollten.
2023.05.06 10:19:12.715 3: Dumper jhash nach decode:
$VAR1 = {
          'tz_dst_auto' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),  <== Hier
          'lng' => '6.89082',
          'mqtt' => {
                      'enable' => $VAR1->{'tz_dst_auto'},           <== Hier
                      'reconnect_timeout_min' => '2',
                      'update_period' => 30,
                      'user' => '',
                      'max_qos' => 0,
                      'reconnect_timeout_max' => '60',
                      'clean_session' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),  <== Hier
                      'server' => '192.168.33.3:1883',
                      'retain' => $VAR1->{'tz_dst_auto'},                 <== Hier
                      'keep_alive' => 60,
                      'id' => 'shellyem3-244CAB42CE6B'
                    },
          'tzautodetect' => $VAR1->{'tz_dst_auto'},                     <== Hier
          'time' => '10:19',
          'timezone' => 'Europe/Berlin',
          'login' => {
                       'unprotected' => $VAR1->{'tz_dst_auto'},             <== Hier
                       'enabled' => $VAR1->{'tz_dst_auto'},           <== Hier
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

meinknopf

Test und GEHT!!!
Danke erstmal und Rückmeldung, Funktioniert!  echt happy
eine Shelly PlugS "Shelly_proc1G" weiterhin OK plus neue Atrribute  :)
eine Shelly PlugS "Shelly_proc2G"  mit den bekannten JSON Fehler (invalid JSON data for device)  geht nun auch und wird erkannt
plus neue Atrribute  :)

Log Auszug:
[Shelly_proc2G:relay] getting relay state for device myShellypoolbadu channel/id 0
[Shelly_proc2G] myShellypoolbadu: Processing metering channel
fhem.pl: Use of uninitialized value $pfactor in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2660.
[Shelly_proc2G] myShellypoolbadu relay voltage=230.2 V, current=4.644 A, power=651.9 W powerfactor=
fhem.pl: Use of uninitialized value $value in string eq at fhem.pl line 5018.

RalfRog

Hat der JSON-Feheler wie bei mir die Autoerkennung verhindert und hast du jetzt mit der Testversion 4.04e getestet?

In 4.04e ist ja decode->"relaxed" ($json = JSON->new->utf8->relaxed;) drin.

.


FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

meinknopf

hmmm, habe mir die 36_Shelly aus diesen Beitrag runtergeladen  "https://forum.fhem.de/index.php?topic=118446.360"
und ins FHEM kopiert und meine Probleme waren gelöst:

Shelly.pm
#
#  FHEM module to communicate with Shelly switch/roller actor devices
#  Prof. Dr. Peter A. Henning, 2022    (v. 4.02f, 3.9.2022)
#  $Id: 36_Shelly.pm 2023-05-06 bfranke $

if( !$jhash ){
      Log3 $name,1,"[Shelly_get_model] standard decoding: has invalid JSON data for device $name";
      $json = JSON->new->utf8->relaxed;
      $jhash = eval{ $json->decode( $data ) };

Jetzt hast Du mich ein wenig verunsichert, hänge hier mal die 4.04.e rein!! sollte ich doch die Falsche erwischt  haben

RalfRog

Zitat von: meinknopf am 09 Mai 2023, 23:11:07...
#  $Id: 36_Shelly.pm 2023-05-06 bfranke $

if( !$jhash ){
      Log3 $name,1,"[Shelly_get_model] standard decoding: has invalid JSON data for device $name";
      $json = JSON->new->utf8->relaxed;
      $jhash = eval{ $json->decode( $data ) };
...

Das sieht wie die letzte Testversion 4.04e vom 6. Mai aus.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

meinknopf

Log Auszug mit häufiger Meldung: Use of uninitialized value $pfactor in concatenation

Verbose 5 gesetzt, Log Auszug, kann ich noch was tun?

2023.05.15 08:39:02 4: [Shelly_proc2G:relay] getting relay state for device myShellypoolbadu channel/id 0
2023.05.15 08:39:02 4: [Shelly_proc2G] myShellypoolbadu: Processing metering channel
[Mon May 15 08:39:02 2023] fhem.pl: Use of uninitialized value $pfactor in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2660.
2023.05.15 08:39:02 4: [Shelly_proc2G] myShellypoolbadu relay voltage=231 V, current=0.054 A, power=2.2 W powerfactor=
[Mon May 15 08:39:02 2023] fhem.pl: Use of uninitialized value $value in string eq at fhem.pl line 5018.
2023.05.15 08:39:02 4: [Shelly_proc2G] myShellypoolbadu: short update in 10 seconds
[Mon May 15 08:39:05 2023] fhem.pl: Use of uninitialized value $pfactor in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2660.
[Mon May 15 08:39:05 2023] fhem.pl: Use of uninitialized value $value in string eq at fhem.pl line 5018.
2023.05.15 08:39:12 4: [Shelly_status] Mode:  relay
2023.05.15 08:39:12 4: [Shelly_status] issue a non-blocking call to http://192.168.178.85/rpc/Switch.GetStatus?id=0
2023.05.15 08:39:12 5: [Shelly_proc2G] =============> Status 2G myShellypoolbadu model shellyplusplugS component relay err  data {"id":0, "source":"http", "output":true, "apower":2.2, "voltage":231.2, "current":0.055, "aenergy":{"total":34806.121,"by_minute":[7.009,36.361,36.361],"minute_ts":1684132750},"temperature":{"tC":27.6, "tF":81.7}}

2023.05.15 08:39:12 4: [Shelly_proc2G] device myShellypoolbadu processing component relay
2023.05.15 08:39:12 5: [Shelly_proc2G] device myShellypoolbadu relay has returned data {"id":0, "source":"http", "output":true, "apower":2.2, "voltage":231.2, "current":0.055, "aenergy":{"total":34806.121,"by_minute":[7.009,36.361,36.361],"minute_ts":1684132750},"temperature":{"tC":27.6, "tF":81.7}}

2023.05.15 08:39:12 4: [Shelly_proc2G:relay] getting relay state for device myShellypoolbadu channel/id 0
2023.05.15 08:39:12 4: [Shelly_proc2G] myShellypoolbadu: Processing metering channel
[Mon May 15 08:39:12 2023] fhem.pl: Use of uninitialized value $pfactor in concatenation (.) or string at ./FHEM/36_Shelly.pm line 2660.
2023.05.15 08:39:12 4: [Shelly_proc2G] myShellypoolbadu relay voltage=231.2 V, current=0.055 A, power=2.2 W powerfactor=
[Mon May 15 08:39:12 2023] fhem.pl: Use of uninitialized value $value in string eq at fhem.pl line 5018.
2023.05.15 08:39:12 4: [Shelly_proc2G] myShellypoolbadu: short update in 10 seconds

RalfRog

Hier ging es an sich um das Thema, dass die Autoerkennung manchmal nicht funktioniert und Starkstrombastler dafür im Code den Paramter Releaxed (decode->"relaxed" ($json = JSON->new->utf8->relaxed;)) als weitere Möglichkeit zur Erkennung eingebaut hat.

Die Autoerkennung geht ja bei dir.
Die Meldungen im Log berichtest du vielleicht besser im Support Thread: https://forum.fhem.de/index.php?topic=118446.0
Den Logauszug steckst du dann am Besten in code-Tags "[ code ][ /code ] ohne Leerzeichen"
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

Starkstrombastler

Hallo meinknopf,
danke für die Rückmeldung. Die Warnung
Zitat von: meinknopf am 15 Mai 2023, 08:42:14Log Auszug mit häufiger Meldung: Use of uninitialized value $pfactor in concatenation
kommt daher, dass offensichtlich nicht alle Shellies einen Wert für Powerfactor liefern. Wird in der nächsten Version berücksichtigt, bitte dann noch mal nachschauen und im oben verlinkten Thread berichten.
IPC\Ubuntu + Fhem, 1wire, Shellies, Siemens Logo!, Z-Wave, PhilipsTV, Vu+duo2, KM200