Closed uKL closed 3 years ago
20:52:47.269 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/set: {"color_temp_startup": "250","color_temp": "250", "brightness": "254"}
20:52:47.269 Expanding json message
20:52:47.271 zigbee2mqtt/0xccccccfffed45a82/set/color##_temp (incoming value 250) skipped - Subscription Filter line 1
20:52:47.271 zigbee2mqtt/0xccccccfffed45a82/set/brightness (incoming value 254) skipped - Subscription Filter line 1
20:52:47.272 zigbee2mqtt/0xccccccfffed45a82/set/color##_temp##_startup (incoming value 250) skipped - Subscription Filter line 1
20:52:47.272 zigbee2mqtt/# matches zigbee2mqtt/0xccccccfffed45a82/set, send to MS 1
20:52:47.274 <INFO> Sent to miniserver 4.35900688171387 msecs
It would be possible to stop processing earlier if everything was filtered, before of the # toMS: Evaluate what Miniservers to send to
.
May save 1 msec. Currently in an to late state before the Pre-Release (more important things to fix).
I'm just wondering about the "Sent to miniserver" line, as everything was filtered, and no element should arrive at the mshttp functions.
Here is where I've put the log
if( $miniservers{$cfg->{Main}{msno}} ) {
foreach ( @toMS ) {
# LOGDEB " HTTP: Sending all values";
my $httpresp;
$httpresp = LoxBerry::MQTTGateway::IO::mshttp_send2($_, %sendhash_noncached);
validate_http_response( $_, \%sendhash_noncached, $httpresp ) if $httpresp;
$httpresp = LoxBerry::MQTTGateway::IO::mshttp_send_mem2($_, %sendhash_cached);
validate_http_response( $_, \%sendhash_cached, $httpresp ) if $httpresp;
if ( scalar keys %sendhash_resetaftersend > 0 ) {
LOGDEB " HTTP: Sending reset-after-send values (delay ".$cfg->{Main}{resetaftersendms}." ms)";
Time::HiRes::sleep($cfg->{Main}{resetaftersendms}/1000);
$httpresp = LoxBerry::MQTTGateway::IO::mshttp_send2($_, %sendhash_resetaftersend);
}
LOGINF "Sent to miniserver " . (Time::HiRes::time() - $beforeSendingTime) * 1000 . " msecs";
}
} else {
LOGERR " HTTP: Cannot send: No Miniserver defined";
}
BTW. Is there any neat way to reload loxberry or the plugin without rebooting the RPi? restarting of the loxberry serving doesn't seem to do that.
In that short time scales also the logging itself needs to be taken into account.
As you are already in "debugging" mode, would you like to comment every LOGxxx line from after MQTT received
up to Sent to miniserver
and check, what the difference is.
Logfile processing is checking the loglevel, open file, add line, close file, and the logfile is stored on a zram compressed ram disk.
Is there any neat way to reload loxberry or the plugin without rebooting the RPi?
I'm not sure what you are for. What do you mean by "reload"? The mqttgateway.pl process can be restarted directly by the webif, or pkill mqttgateway.pl and restarting it from shell.
I'm not sure what you are for. What do you mean by "reload"? The mqttgateway.pl process can be restarted directly by the webif, or pkill mqttgateway.pl and restarting it from shell.
That's exactly what I needed :) I'm newbie to PERL, I'm proficient with Java & Kotlin and programmed for a few years in PHP.
22:23:15.752 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/linkquality: 39
22:23:15.754 <INFO> Sent to miniserver 1.20210647583008 msecs
22:23:15.755 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/battery: 87
22:23:15.757 <INFO> Sent to miniserver 1.28793716430664 msecs
22:23:15.758 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/update_available: true
22:23:15.760 <INFO> Sent to miniserver 1.19209289550781 msecs
22:23:15.761 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/click: off
22:23:15.772 <INFO> Sent to miniserver 10.4401111602783 msecs
22:23:15.773 <OK> UDP IN: (192.168.3.254): zigbee2mqtt/0xccccccfffed45a82/set {"color_temp_startup": "250","color_temp": "250", "brightness": "0"}
22:23:15.774 Publishing: 'zigbee2mqtt/0xccccccfffed45a82/set'='{"color_temp_startup": "250","color_temp": "250", "brightness": "0"}'
22:23:15.780 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/set: {"color_temp_startup": "250","color_temp": "250", "brightness": "0"}
22:23:15.782 <INFO> Sent to miniserver 1.60694122314453 msecs
22:23:15.887 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: OFF
22:23:15.889 <INFO> Sent to miniserver 0.905990600585938 msecs
22:23:15.890 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
22:23:15.891 <INFO> Sent to miniserver 0.924110412597656 msecs
22:23:15.892 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
22:23:15.894 <INFO> Sent to miniserver 1.00302696228027 msecs
22:23:15.894 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
22:23:15.896 <INFO> Sent to miniserver 0.993967056274414 msecs
22:23:15.897 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
22:23:15.898 <INFO> Sent to miniserver 0.929117202758789 msecs
22:23:15.980 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: OFF
22:23:15.981 <INFO> Sent to miniserver 0.975131988525391 msecs
22:23:15.982 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
22:23:15.983 <INFO> Sent to miniserver 0.905990600585938 msecs
22:23:15.984 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
22:23:15.986 <INFO> Sent to miniserver 0.974893569946289 msecs
22:23:15.986 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
22:23:15.988 <INFO> Sent to miniserver 0.976800918579102 msecs
22:23:15.989 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
22:23:15.991 <INFO> Sent to miniserver 1.67608261108398 msecs
Here are results. First response from the MS comes after 22ms! Entire process takes 239ms.
Another thing, I've dumped what goes to IO::mshttp
22:27:13.119 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/linkquality: 44
22:27:13.120 HTTP: Will send to MS: $VAR1 = {};
22:27:13.121 <INFO> Sent to miniserver 1.91998481750488 msecs
22:27:13.122 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/battery: 87
22:27:13.123 HTTP: Will send to MS: $VAR1 = {
'zigbee2mqtt_0xccccccfffee2762f_battery' => '87'
};
22:27:13.124 <INFO> Sent to miniserver 1.89900398254395 msecs
22:27:13.125 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/update_available: true
22:27:13.126 HTTP: Will send to MS: $VAR1 = {};
22:27:13.127 <INFO> Sent to miniserver 1.80888175964355 msecs
22:27:13.128 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/click: on
22:27:13.139 HTTP: Will send to MS: $VAR1 = {};
22:27:13.140 <INFO> Sent to miniserver 12.1700763702393 msecs
22:27:13.343 <INFO> Executing DNS reverse lookup
22:27:13.343 <OK> UDP IN: (192.168.3.254): zigbee2mqtt/0xccccccfffed45a82/set {"color_temp_startup": "250","color_temp": "250", "brightness": "254"}
22:27:13.344 Publishing: 'zigbee2mqtt/0xccccccfffed45a82/set'='{"color_temp_startup": "250","color_temp": "250", "brightness": "254"}'
22:27:13.347 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/set: {"color_temp_startup": "250","color_temp": "250", "brightness": "254"}
22:27:13.349 HTTP: Will send to MS: $VAR1 = {};
22:27:13.350 <INFO> Sent to miniserver 2.76684761047363 msecs
22:27:13.448 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: ON
22:27:13.449 HTTP: Will send to MS: $VAR1 = {};
22:27:13.450 <INFO> Sent to miniserver 1.5261173248291 msecs
22:27:13.452 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
22:27:13.453 HTTP: Will send to MS: $VAR1 = {};
22:27:13.454 <INFO> Sent to miniserver 1.5568733215332 msecs
22:27:13.455 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
22:27:13.456 HTTP: Will send to MS: $VAR1 = {
'zigbee2mqtt_0xccccccfffed45a82_brightness' => '254'
};
22:27:13.457 <INFO> Sent to miniserver 1.70588493347168 msecs
22:27:13.457 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
22:27:13.459 HTTP: Will send to MS: $VAR1 = {
'zigbee2mqtt_0xccccccfffed45a82_color_temp' => '250'
};
22:27:13.459 <INFO> Sent to miniserver 1.66487693786621 msecs
22:27:13.460 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
22:27:13.461 HTTP: Will send to MS: $VAR1 = {};
22:27:13.462 <INFO> Sent to miniserver 1.79815292358398 msecs
22:27:13.539 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: ON
22:27:13.539 HTTP: Will send to MS: $VAR1 = {};
22:27:13.540 <INFO> Sent to miniserver 1.13010406494141 msecs
22:27:13.540 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
22:27:13.541 HTTP: Will send to MS: $VAR1 = {};
22:27:13.542 <INFO> Sent to miniserver 1.1441707611084 msecs
22:27:13.542 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
22:27:13.543 HTTP: Will send to MS: $VAR1 = {
'zigbee2mqtt_0xccccccfffed45a82_brightness' => '254'
};
22:27:13.544 <INFO> Sent to miniserver 1.21808052062988 msecs
22:27:13.544 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
22:27:13.545 HTTP: Will send to MS: $VAR1 = {
'zigbee2mqtt_0xccccccfffed45a82_color_temp' => '250'
};
22:27:13.545 <INFO> Sent to miniserver 1.19400024414062 msecs
22:27:13.546 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
22:27:13.547 HTTP: Will send to MS: $VAR1 = {};
22:27:13.547 <INFO> Sent to miniserver 1.12295150756836 msecs
As you can see, even if the hash is empty, it goes to the output pipe. I've introduced a following condition:
if (%sendhash_noncached) {
#LOGDEB " HTTP: Will send non-cached to MS: ".Dumper(\%sendhash_noncached);
$httpresp = LoxBerry::MQTTGateway::IO::mshttp_send2($_, %sendhash_noncached);
validate_http_response( $_, \%sendhash_noncached, $httpresp ) if $httpresp;
}
if (%sendhash_cached) {
#LOGDEB " HTTP: Will send cached to MS: ".Dumper(\%sendhash_cached);
$httpresp = LoxBerry::MQTTGateway::IO::mshttp_send_mem2($_, %sendhash_cached);
validate_http_response( $_, \%sendhash_cached, $httpresp ) if $httpresp;
}
Which resulted in total processing time of ~211ms (part of that is the zigbee communication itself)
22:36:21.694 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/linkquality: 55
22:36:21.695 <INFO> Sent to miniserver 0.580072402954102 msecs
22:36:21.696 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/battery: 87
22:36:21.698 <INFO> Sent to miniserver 1.29294395446777 msecs
22:36:21.699 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/update_available: true
22:36:21.700 <INFO> Sent to miniserver 0.570058822631836 msecs
22:36:21.701 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/click: off
22:36:21.713 <INFO> Sent to miniserver 11.7189884185791 msecs
22:36:21.714 <OK> UDP IN: (192.168.3.254): zigbee2mqtt/0xccccccfffed45a82/set {"color_temp_startup": "250","color_temp": "250", "brightness": "0"}
22:36:21.714 Publishing: 'zigbee2mqtt/0xccccccfffed45a82/set'='{"color_temp_startup": "250","color_temp": "250", "brightness": "0"}'
22:36:21.718 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/set: {"color_temp_startup": "250","color_temp": "250", "brightness": "0"}
22:36:21.720 <INFO> Sent to miniserver 1.11103057861328 msecs
22:36:21.815 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: OFF
22:36:21.816 <INFO> Sent to miniserver 0.411033630371094 msecs
22:36:21.816 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
22:36:21.817 <INFO> Sent to miniserver 0.40888786315918 msecs
22:36:21.818 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
22:36:21.819 <INFO> Sent to miniserver 1.04093551635742 msecs
22:36:21.820 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
22:36:21.821 <INFO> Sent to miniserver 1.06287002563477 msecs
22:36:21.822 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
22:36:21.823 <INFO> Sent to miniserver 0.462055206298828 msecs
22:36:21.896 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: OFF
22:36:21.896 <INFO> Sent to miniserver 0.396966934204102 msecs
22:36:21.898 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
22:36:21.899 <INFO> Sent to miniserver 0.473976135253906 msecs
22:36:21.900 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
22:36:21.901 <INFO> Sent to miniserver 1.1448860168457 msecs
22:36:21.902 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
22:36:21.904 <INFO> Sent to miniserver 1.16682052612305 msecs
22:36:21.904 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
22:36:21.905 <INFO> Sent to miniserver 0.505924224853516 msecs
It's not at a level that is satisfying but further optimizations are possible:
To "if" the sendhash variables before calling mshttp doesn't really make the request cheaper, as the if is already in mshttp, and in 99% of cases, somethings needs to be sent (and if filtered, who cares that doing nothing took half a msec longer as needed).
json expansion is needed as all filters work on expanded data.
Preparing data for incoming overview is copying pointers in memory. I want to have the state in memory.
Multithreading is really something I'm thinking of, but only for the Transformer handling. Perl has not very good Multithreading support (it's used in Squeezelite Plugin), and Thread handling will take up the double of the 1 msec that can be eliminated out of 4.
Currently, I only see further performance needs in the UI with additional filters, because data increases. The processing delay is required as otherwise it will freeze our Miniserver Gen. 1.
Would you test this easy change that quits message processing early, if nothing is left after the filters?
(and if filtered, who cares that doing nothing took half a msec longer as needed).
Well, actually, the processing is not concurrent. Basically, if my zigbee device reports 15 topics (and unfortunately the last one is /click
), that means I've wasted 15 millis (at least, if each takes 1ms) before I knew about the click.
The change you've added in f693e65 works fine. Good job!
08:36:16.492 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/linkquality: 57
08:36:16.493 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/battery: 34
08:36:16.495 <INFO> Sent to miniserver 1.36017799377441 msecs
08:36:16.496 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/update_available: true
08:36:16.497 <INFO> MQTT received: zigbee2mqtt/0xccccccfffee2762f/click: off
08:36:16.509 <INFO> Sent to miniserver 12.4340057373047 msecs
08:36:16.510 <OK> UDP IN: (192.168.3.254): zigbee2mqtt/0xccccccfffed45a82/set {"color_temp_startup": "250","color_temp": "250", "brightness": "0"}
08:36:16.514 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/set: {"color_temp_startup": "250","color_temp": "250", "brightness": "0"}
08:36:16.610 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: OFF
08:36:16.610 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
08:36:16.611 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
08:36:16.612 <INFO> Sent to miniserver 1.11103057861328 msecs
08:36:16.613 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
08:36:16.614 <INFO> Sent to miniserver 1.11103057861328 msecs
08:36:16.615 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
08:36:16.696 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/state: OFF
08:36:16.696 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/linkquality: 60
08:36:16.698 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/brightness: 254
08:36:16.700 <INFO> Sent to miniserver 1.14297866821289 msecs
08:36:16.700 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/color_temp: 250
08:36:16.701 <INFO> Sent to miniserver 1.11508369445801 msecs
08:36:16.702 <INFO> MQTT received: zigbee2mqtt/0xccccccfffed45a82/update_available: true
The processing delay is required as otherwise it will freeze our Miniserver Gen. 1.
I'm not aware of issues with Gen 1, I'm just starting with Loxone :) I was comparing to my previous setup with OpenHAB which had almost no delay (stronger machine, direct MQTT connection).
What is your LoxWiki account name?
What is your LoxWiki account name?
Try this: 69d683c
I haven't noticed any significant performance changes. Might be better with more significant load but not in my case.
What is your performance setting at the Settings tab (I suppose it is "Very fast" or "No limits"). In that case, the Pid controller in the Gateway may have reduced to delay to nearly 0, so the "Fast Response Mode" cannot do any further improvements. This mode skips the loop delay in case that data were processed in the last round.
Perl (or PHP) is not a callback language. Using e. g. Node.js wouldn't require to have fetching loops. But the MQTT and UDP link in the Gateway ARE open connections! Fetching is not done from the broker, but from the socket buffer.
What is your LoxWiki account name?
This is not LoxWiki, this is Loxforum.
I somehow thought they share one account & it turned out I didn't have any. Here it is pawel.urban
.
in fact, I was on default setting (Fast). Whenever I try changing that I see "Error saving" error message.
Check https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+2.0+What%27s+New https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Transformers
If you thing the saving error is an issue (and not happened of your changes to the Gateway), please open an issue with screenshot of the error (and if possible F12 Dev Tools Error message, if one exists).
Thanks, good job! :) I think we can close this issue for now.
If fact, the issue I was seeing with the config was related to the config file access rights. It has been altered when I ran the mqttgateway from the console (as root sadly). Now all good. Will check how this affects performance later.
I'll close the issue. For still more performance, we need more MHz at Raspberry and Miniserver ;-)
First of all, great job with 2.0 :) I've tested it due to lagging issues (I've described on loxforum)
Overall experience is great but the subscription filters are somehow still consuming some processing time, even if the result is set to be ignored. I've added some logs to see how long the
sub received
takes.Here are some logs
What you can see, that most of the topics are ignored due to regexp filtering but their processing is summing up to around 30 millis - and this is only a button press and a lamp turning on.