mschlenstedt / Loxberry

Current stable Branch is: *** Please see Releases *** Current developer Branch is: *** master ***
Apache License 2.0
77 stars 27 forks source link

MQTT - Flat array with plain values expanded incorrectly #1424

Open sebastianstolzenberg opened 1 year ago

sebastianstolzenberg commented 1 year ago

A json array with plain numbers is expanded incorrectly.

16:13:17.402 MQTT IN: go-eCharger/221889/nrg: [229.71,2.17,2.17,3.72,0,0,0,0,0,0,0,0,0,0,0,0] 16:13:17.403 Expanding json message 16:13:17.403 Plain json array was converted to hash 16:13:17.404 go-eCharger/221889/nrg/3.72 = 1 16:13:17.405 go-eCharger/221889/nrg/0 = 1 16:13:17.405 go-eCharger/221889/nrg/2.17 = 1 16:13:17.405 go-eCharger/221889/nrg/229.71 = 1

sebastianstolzenberg commented 1 year ago

The following change in mqttgateway.pl leads to the desired output.

diff --git a/sbin/mqttgateway.pl b/sbin/mqttgateway.pl
index 929e87df..767b8c12 100755
--- a/sbin/mqttgateway.pl
+++ b/sbin/mqttgateway.pl
@@ -431,7 +431,8 @@ sub received
                        undef $@;
                        eval {
                                if( ref($contjson) eq "ARRAY" ) {
-                                       my %tmphash = map { $_ => 1 } @$contjson;
+                                       my $key = 0;
+                                       my %tmphash = map { $key++ => $_ } @$contjson;
                                        $contjson = \%tmphash;
                                        LOGDEB "Plain json array was converted to hash";
                                }

which produces the following output:

17:12:35.471 OK: MQTT IN: go-eCharger/221889/nrg: [227.23,2.17,1.86,3.72,0,0,0,0,0,0,0,0,0,0,0,0]
17:12:35.472 Expanding json message
17:12:35.472 Plain json array was converted to hash
17:12:35.474 go-eCharger/221889/nrg/11 = 0
17:12:35.474 go-eCharger/221889/nrg/3 = 3.72
17:12:35.475 go-eCharger/221889/nrg/14 = 0
17:12:35.475 go-eCharger/221889/nrg/8 = 0
17:12:35.475 go-eCharger/221889/nrg/13 = 0
17:12:35.475 go-eCharger/221889/nrg/1 = 2.17
17:12:35.475 go-eCharger/221889/nrg/5 = 0
17:12:35.475 go-eCharger/221889/nrg/10 = 0
17:12:35.476 go-eCharger/221889/nrg/12 = 0
17:12:35.476 go-eCharger/221889/nrg/15 = 0
17:12:35.476 go-eCharger/221889/nrg/7 = 0
17:12:35.476 go-eCharger/221889/nrg/9 = 0
17:12:35.476 go-eCharger/221889/nrg/2 = 1.86
17:12:35.477 go-eCharger/221889/nrg/6 = 0
17:12:35.477 go-eCharger/221889/nrg/4 = 0
17:12:35.477 go-eCharger/221889/nrg/0 = 227.23
christianTF commented 1 year ago

This is the same issue as https://github.com/mschlenstedt/Loxberry/issues/1383

Array parsing is difficult because of the missing key in an array, and different expectations how the result should be forwarded.

The current implementation has the functionality to get/find a concrete element in an array by setting the elements to TRUE.

In an array [„orange“, „apple“, „strawberry“] it allows to find the element „orange“ on the Miniserver. As the key is missing, and array elements don’t have a defined size (number of elements), internally creating a key (0, 1, 2,…) may lead to unexpected results if the element count changes.

Currently no idea how to handle this in a generic way.

sebastianstolzenberg commented 1 year ago

I see. Maybe providing both solutions in parallel is an approach that would make all of us happy. Each array could be expanded into an index based representation and into one that is value-presence based.

I.e. in my case go-eCharger/221889/nrg: [227.23,2.17,1.86,3.72,0,0,0,0,0,0,0,0,0,0,0,0] could be expanded into:

  1. go-eCharger_221889_nrg_i_0 to go-eCharger_221889_nrg_i_15 containing the values at the respective indices.
  2. go-eCharger_221889_nrg_v_0, go-eCharger_221889_nrg_v_3.72 and so on to indicate the presence of a value.
christianTF commented 1 year ago

Yes, good idea. By disabling of forwarding, or filtering, the forwarding load to the Miniserver can be manually reduced by the user.