openweather plugin ?

[ArcherS]

@akbooer what I have seen is that in the "testing" release it seems as if the checkmarks in the Hstorian disappear, at east for me. When I check a variable the check is gone when I return to the Historian.

Despite this I have historical data when looking at a graph, e.g:

I have not connected my test Pi to Grafana, but I assume that if the graph in Historian contains data so should a graph in Grafana.

@Buxton what I have noticed is that Tasmota for BLE sometimes freezes, at least for me running the beta on an ESP32. It seems that it deliveres the same value every time over Mqtt, I assume that OpenLuup then acts on this and that is why the data is not there in Historian.
In fact when I read you report I checked my data for one of the BLE variables and it was gone. A restart of the Tasmota BLE device fixed that and now data is back.

[ArcherS]

@therealdb said in openLuup: Tasmota MQTT Bridge:

@archers no need to put ip or anything. Just push the mqtt message to the broker. In you case

I have tried this, but it seems not to work for some strange reason.
I put the Mqtt message in the "MQTT_PowerStatusOn" variable but I do not get any Mqtt message in either the Tasmota Console or in Mqtt Explorer when toggling the device, I assume that it should react when doing that.

Any ideas on what could be wrong?

Just for comparison, when testing this in the Lua Code Test it works, so the messsage should be ok.

luup.openLuup.mqtt.publish ("cmnd/TasmotaIR/IRhvac","{\"Vendor\":\"FUJITSU_AC\",\"Model\":1,\"Mode\":\"Heat\",\"Power\":\"On\",\"Celsius\":\"On\",\"Temp\":20,\"FanSpeed\":\"Auto\",\"SwingV\":\"Off\",\"SwingH\":\"Off\",\"Quiet\":\"Off\",\"Turbo\":\"Off\",\"Econo\":\"Off\",\"Light\":\"Off\",\"Filter\":\"Off\",\"Clean\":\"Off\",\"Beep\":\"Off\",\"Sleep\":-1}")

[therealdb]

@archers oh, my bad. This is to catch an event associated to on. If you want to trigger on, you should use the Standard on variable. Let me go back to my pc and I’ll post a working sample.

[therealdb]

@archers so, to execute something when you turn a device ON, just add this as the SetPowerURL variable's value:

mqtt://cmnd/TasmotaIR/IRhvac/=/{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

(Notice the mqtt:// prefix that I omitted from the docs - my bad).

I've not implemented thermostats yet, but I could do it easily, grabbing some code from the heaters.

[ArcherS]

@therealdb thanks, that works!
A useful addition to the Mqtt setup in OpenLuup for sure.

[akbooer]

@archers said in openLuup: Tasmota MQTT Bridge:

Despite this I have historical data when looking at a graph

Yes, this works even if the Historian is not archiving to disk. It maintains an in-memory cache of the 1000, or so, latest values for numeric variables.

@archers said in openLuup: Tasmota MQTT Bridge:

I assume that if the graph in Historian contains data so should a graph in Grafana.

Not so. This cache is not available to Grafana, which requires an on-disk archive. This behaviour is described in some detail on pp.12–13 of the User Guide.

@Buxton, you have two options:

1. create the archive files manually (using the correct attributes.) Once they're there, the Historian will continue to write to them.
2. Let me know the variable names (I'm assuming Temperature and Humidity?) and I will add them to the archive defaults.

#2 is obviously the better option.

[ArcherS]

@therealdb said in openLuup: Tasmota MQTT Bridge:

I've not implemented thermostats yet, but I could do it easily, grabbing some code from the heaters.

I have the idea to control the temperature of my HVAC and looked at your VirtualHeater device.
For some reason it does not seem to keep the values I set when changing the temperature. Any ideas?

My first thought is to keep things simple. A hetater or thermostat device for setting the temp and possibly something more. Maybe fan speed also later on.

[ArcherS]

@akbooer said in openLuup: Tasmota MQTT Bridge:

Not so. This cache is not available to Grafana, which requires an on-disk archive. This behaviour is described in some detail on pp.12–13 of the User Guide.

I had forgotten about setting that up on my main OpenLuup server, but that of course explains the difference with my test server.

@Buxton, you have two options:

create the archive files manually (using the correct attributes.) Once they're there, the Historian will continue to write to them.
Let me know the variable names (I'm assuming Temperature and Humidity?) and I will add them to the archive defaults.

On my BLE Tasmota it is Temperature, Humidity and Battery (for my LYWSD03MMC Xiaomi BLE sensors).

[therealdb]

@archers I need verbose logs. I have mine setup this way to control a dehumidifier and it’s working ok.

[Buxton]

@akbooer Yes, I'm starting to see what your up against here. MQTT, because of its flexibility, is not going fit into established serviceiDs. Developing a UI to manage this complexity will take some creative insight.....

Attached is a sample screenshot of the device file. Note the three sensors listed on the left with non-friendly names

And here is the actual device file as displayed in the console:

[{
  "ControlURLs":[],
  "altid":"power_BedroomTV",
  "category_num":0,
  "device_file":"D_GenericTasmotaDevice.xml",
  "device_json":"D_GenericTasmotaDevice.json",
  "device_type":"GenericTasmotaDevice",
  "disabled":0,
  "id":30001,
  "id_parent":262,
  "invisible":"0",
  "ip":"",
  "local_udn":"uuid:d764c8cc-e932-55c4-478d-7aa05d83f3ea",
  "mac":"",
  "manufacturer":"could be anyone",
  "model":"",
  "name":"power_BedroomTV",
  "plugin":"",
  "room":"35",
  "states":[{
    "id":0,
    "service":"urn:micasaverde-com:serviceId:HaDevice1",
    "value":"1620676905",
    "variable":"LastUpdate"
  },{
    "id":1,
    "service":"power_BedroomTV",
    "value":"{\"Time\":\"2021-05-10T21:01:44\",\"Switch1\":\"ON\",\"Switch2\":\"ON\",\"ENERGY\":{\"TotalStartTime\":\"2021-04-04T05:29:11\",\"Total\":0.000,\"Yesterday\":0.000,\"Today\":0.000,\"Period\":0,\"Power\":[0,0],\"ApparentPower\":[0,0],\"ReactivePower\":[0,0],\"Factor\":[0.00,0.00],\"Frequency\":60,\"Voltage\":121,\"Current\":[0.000,0.000]}}",
    "variable":"tele"
  },{
    "id":2,
    "service":"LYWSD03eb4f4f",
    "value":"a4c138eb4f4f",
    "variable":"mac"
  },{
    "id":3,
    "service":"LYWSD03eb4f4f",
    "value":"21.7",
    "variable":"Temperature"
  },{
    "id":4,
    "service":"LYWSD03eb4f4f",
    "value":"62",
    "variable":"Humidity"
  },{
    "id":5,
    "service":"LYWSD03eb4f4f",
    "value":"-74",
    "variable":"RSSI"
  },{
    "id":6,
    "service":"LYWSD03eb4f4f",
    "value":"14.1",
    "variable":"DewPoint"
  },{
    "id":7,
    "service":"power_BedroomTV",
    "value":"2021-05-10T21:01:44",
    "variable":"Time"
  },{
    "id":8,
    "service":"LYWSD0338eb2e",
    "value":"a4c13838eb2e",
    "variable":"mac"
  },{
    "id":9,
    "service":"LYWSD0338eb2e",
    "value":"21.6",
    "variable":"Temperature"
  },{
    "id":10,
    "service":"LYWSD0338eb2e",
    "value":"54",
    "variable":"Humidity"
  },{
    "id":11,
    "service":"LYWSD0338eb2e",
    "value":"-85",
    "variable":"RSSI"
  },{
    "id":12,
    "service":"LYWSD0338eb2e",
    "value":"11.9",
    "variable":"DewPoint"
  },{
    "id":13,
    "service":"LYWSD03a59e0c",
    "value":"a4c138a59e0c",
    "variable":"mac"
  },{
    "id":14,
    "service":"LYWSD03a59e0c",
    "value":"20.9",
    "variable":"Temperature"
  },{
    "id":15,
    "service":"LYWSD03a59e0c",
    "value":"58",
    "variable":"Humidity"
  },{
    "id":16,
    "service":"LYWSD03a59e0c",
    "value":"-91",
    "variable":"RSSI"
  },{
    "id":17,
    "service":"LYWSD03a59e0c",
    "value":"12.3",
    "variable":"DewPoint"
  },{
    "id":18,
    "service":"power_BedroomTV",
    "value":"ON",
    "variable":"Switch2"
  },{
    "id":19,
    "service":"power_BedroomTV",
    "value":"ON",
    "variable":"Switch1"
  },{
    "id":20,
    "service":"ENERGY",
    "value":"0",
    "variable":"Total"
  },{
    "id":21,
    "service":"ENERGY",
    "value":"table: 0x556c23b0f060",
    "variable":"Power"
  },{
    "id":22,
    "service":"ENERGY",
    "value":"table: 0x556c23b0f100",
    "variable":"ApparentPower"
  },{
    "id":23,
    "service":"ENERGY",
    "value":"table: 0x556c237e4cd0",
    "variable":"Current"
  },{
    "id":24,
    "service":"ENERGY",
    "value":"121",
    "variable":"Voltage"
  },{
    "id":25,
    "service":"ENERGY",
    "value":"table: 0x556c237e48d0",
    "variable":"Factor"
  },{
    "id":26,
    "service":"ENERGY",
    "value":"0",
    "variable":"Period"
  },{
    "id":27,
    "service":"ENERGY",
    "value":"table: 0x556c23b0f1d0",
    "variable":"ReactivePower"
  },{
    "id":28,
    "service":"ENERGY",
    "value":"0",
    "variable":"Yesterday"
  },{
    "id":29,
    "service":"ENERGY",
    "value":"2021-04-04T05:29:11",
    "variable":"TotalStartTime"
  },{
    "id":30,
    "service":"ENERGY",
    "value":"0",
    "variable":"Today"
  },{
    "id":31,
    "service":"ENERGY",
    "value":"60",
    "variable":"Frequency"
  },{
    "id":32,
    "service":"ENERGY",
    "value":"0",
    "variable":"Power/1"
  },{
    "id":33,
    "service":"ENERGY",
    "value":"0",
    "variable":"Power/2"
  },{
    "id":34,
    "service":"ENERGY",
    "value":"0",
    "variable":"ApparentPower/1"
  },{
    "id":35,
    "service":"ENERGY",
    "value":"0",
    "variable":"ApparentPower/2"
  },{
    "id":36,
    "service":"ENERGY",
    "value":"0",
    "variable":"Current/1"
  },{
    "id":37,
    "service":"ENERGY",
    "value":"0",
    "variable":"Current/2"
  },{
    "id":38,
    "service":"ENERGY",
    "value":"0",
    "variable":"Factor/1"
  },{
    "id":39,
    "service":"ENERGY",
    "value":"0",
    "variable":"Factor/2"
  },{
    "id":40,
    "service":"ENERGY",
    "value":"0",
    "variable":"ReactivePower/1"
  },{
    "id":41,
    "service":"ENERGY",
    "value":"0",
    "variable":"ReactivePower/2"
  },{
    "id":42,
    "service":"power_BedroomTV",
    "value":"50",
    "variable":"Sleep"
  },{
    "id":43,
    "service":"power_BedroomTV",
    "value":"56414",
    "variable":"UptimeSec"
  },{
    "id":44,
    "service":"power_BedroomTV",
    "value":"Dynamic",
    "variable":"SleepMode"
  },{
    "id":45,
    "service":"power_BedroomTV",
    "value":"OFF",
    "variable":"POWER2"
  },{
    "id":46,
    "service":"power_BedroomTV",
    "value":"OFF",
    "variable":"POWER1"
  },{
    "id":47,
    "service":"power_BedroomTV",
    "value":"125",
    "variable":"Heap"
  },{
    "id":48,
    "service":"Wifi",
    "value":"CD",
    "variable":"SSId"
  },{
    "id":49,
    "service":"Wifi",
    "value":"FE:9F:DB:F5:A0:11",
    "variable":"BSSId"
  },{
    "id":50,
    "service":"Wifi",
    "value":"0T00:00:26",
    "variable":"Downtime"
  },{
    "id":51,
    "service":"Wifi",
    "value":"11",
    "variable":"Channel"
  },{
    "id":52,
    "service":"Wifi",
    "value":"86",
    "variable":"RSSI"
  },{
    "id":53,
    "service":"Wifi",
    "value":"2",
    "variable":"LinkCount"
  },{
    "id":54,
    "service":"Wifi",
    "value":"-57",
    "variable":"Signal"
  },{
    "id":55,
    "service":"Wifi",
    "value":"1",
    "variable":"AP"
  },{
    "id":56,
    "service":"power_BedroomTV",
    "value":"2",
    "variable":"MqttCount"
  },{
    "id":57,
    "service":"power_BedroomTV",
    "value":"0T15:40:14",
    "variable":"Uptime"
  },{
    "id":58,
    "service":"power_BedroomTV",
    "value":"19",
    "variable":"LoadAvg"
  }],
  "status":-1,
  "subcategory_num":0,
  "time_created":1618456263
}]

[ArcherS]

@therealdb said in openLuup: Tasmota MQTT Bridge:

@archers I need verbose logs. I have mine setup this way to control a dehumidifier and it’s working ok.

I set the debugmode variable to 1. In the ReadMe it says logs could be captured by navigating to http://VeraIP/cgi-bin/cmh/log.sh?Device=LuaUPnP but this does not seem to work, is it another url for OpenLuup? Or can I find the log somewhere in cmh-ludl?

Just to clarify, the device is still not connected to anything (no IP given) could that be the reason, or should it work anyway?

[therealdb]

@archers it should work regardless. The openluup log page is under /console

[akbooer]

@ArcherS, @Buxton

Latest openLuup development version (v21.5.10, and yes, we're back to that branch) includes fixes for Tasmota (and Shelly) Historian, including archive rules for Temperature / Humidity / Battery variable names.

Please Note: you should reload openLuup once more after updating, to get the Historian and Grafana to sync properly.

[ArcherS]

@therealdb said in openLuup: Tasmota MQTT Bridge:

@archers it should work regardless. The openluup log page is under /console

Aha, I thought it ended up in a separate logfile.

This is what I get in the log when changing the temperature of the device (no 50):

2021-05-10 22:59:37.312   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=50&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=15 HTTP/1.1 tcp{client}: 0x1ec57b0
2021-05-10 22:59:37.313   luup.call_action:: 50.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 
2021-05-10 22:59:37.314   luup_log:50: VirtualDevices[3.0-beta2@50](actionSetCurrentSetpoint@86):actionSetCurrentSetpoint(50,"15","Off","Heating")
2021-05-10 22:59:37.314   luup_log:50: VirtualDevices[3.0-beta2@50](actionSetCurrentSetpoint@90):actionSetCurrentSetpoint: skipped
2021-05-10 22:59:37.315   openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x1ec57b0
2021-05-10 22:59:50.043   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1ec57b0

[Buxton]

@akbooer OK that worked. Thx

Edit: Humidity variables are back. Looks like about 4 hours passed

I still do not see the humidity variables on the cache page though. The humidity values have recently updated as a scene I run based on humidity trigger points, fired about an hour ago.

[Buxton]

@akbooer One small error creating the energy variables

2021-05-10 17:22:42.275   openLuup.context_switch::  ERROR: [dev #0] ./openLuup/whisper.lua:662: Cannot create file '%s'
2021-05-10 17:22:42.275   openLuup.scheduler:: 30001.ENERGY.Current/1 ERROR ./openLuup/whisper.lua:662: Cannot create file '%s' function: 0x5633603dd490
2021-05-10 17:22:42.276   openLuup.context_switch::  ERROR: [dev #0] ./openLuup/whisper.lua:662: Cannot create file '%s'
2021-05-10 17:22:42.276   openLuup.scheduler:: 30001.ENERGY.Current/2 ERROR ./openLuup/whisper.lua:662: Cannot create file '%s' function: 0x5633603dd490

[therealdb]

@archers said in openLuup: Tasmota MQTT Bridge:

This is what I get in the log when changing the temperature of the device (no 50):

Looking at the logs, you're setting the temperature while the heater is off, so it's skipped. Do you want to turn it on if the temperature is below the target?

[akbooer]

@buxton said in openLuup: Tasmota MQTT Bridge:

Humidity variables are back. Looks like about 4 hours passed

Yes, that's not unexpected. In fact, it requires two variable updates before the variable appears on the historian list (because many, otherwise untinteresting, variables are updated once at startup.)

@buxton said in openLuup: Tasmota MQTT Bridge:

One small error creating the energy variables

Ah yes, those pesky topic separators '/' in the variable name – I knew it would come back to bite me. They are, of course, in the Unix file world, directory path separators. Some work required on the HIstorian filename handling...

[akbooer]

@Buxton

@akbooer said in openLuup: Tasmota MQTT Bridge:

Some work required on the HIstorian filename handling...

...now done in latest development version v21.5.11.

[ArcherS]

@therealdb said in openLuup: Tasmota MQTT Bridge:

Looking at the logs, you're setting the temperature while the heater is off, so it's skipped. Do you want to turn it on if the temperature is below the target?

I created a new device just to start from fresh:

When I try to change the dropdown from "off" to "Heat" it reverts back after I e.g. change rooms or reload the browser. The same thing when changing the temperature. Should it not stay at the value I set? I may be missing something obvious here on how the heater controller works, since it is the first time I play around with one.

These are the attributes:

and the variables:

The current temp was at 2000 when the device was created, tried changing it to e.g. 20, but makes no difference.

Some log entries from when changing the values:

2021-05-11 16:04:04.239   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=21 HTTP/1.1 tcp{client}: 0x2697800
2021-05-11 16:04:04.242   luup.call_action:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 
2021-05-11 16:04:04.243   openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x2697800
2021-05-11 16:04:09.775   openLuup.server:: GET /cmh/skins/default/img/devices/device_states/dimmable_light_30.png HTTP/1.1 tcp{client}: 0x2697800
2021-05-11 16:04:09.777   openLuup.server:: request completed (938 bytes, 0 chunks, 0 ms) tcp{client}: 0x2697800
2021-05-11 16:04:16.134   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x2697800

2021-05-11 16:05:43.757   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=741810207&Timeout=60&MinimumDelay=1500&_=1620741805209 HTTP/1.1 tcp{client}: 0x2882ed8
2021-05-11 16:05:45.244   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:HVAC_UserOperatingMode1&action=SetModeTarget&NewMode=HeatOn HTTP/1.1 tcp{client}: 0x2d32838
2021-05-11 16:05:45.246   luup.call_action:: 52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.SetModeTarget 
2021-05-11 16:05:45.247   openLuup.server:: request completed (39 bytes, 1 chunks, 1 ms) tcp{client}: 0x2d32838
2021-05-11 16:05:53.818   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x2d32838

Log from when the device was created:

2021-05-11 10:05:35.089   luup.create_device:: [52] D_VirtualHeater1.xml / I_VirtualHeater1.xml / D_Heater1.json   (urn:schemas-upnp-org:device:Heater:1)
2021-05-11 10:05:35.099   openLuup.server:: request completed (6440 bytes, 0 chunks, 34 ms) tcp{client}: 0x1c6c030
2021-05-11 10:05:35.099   openLuup.scheduler:: [52] VirtualHeater2 device startup
2021-05-11 10:05:35.099   luup_log:52: VirtualHeater starting...
2021-05-11 10:05:35.100   luup_log:52: VirtualDevices[3.0-beta2@52]:Plugin starting
2021-05-11 10:05:35.100   luup.device_message:: device=52, status=4, message=Starting..., timeout=5, source=VirtualDevices
2021-05-11 10:05:35.100   luup_log:52: VirtualDevices[3.0-beta2@52]:Child #52 - "VirtualHeater2"
2021-05-11 10:05:35.101   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.DebugMode was: EMPTY now: 0 #hooks:0
2021-05-11 10:05:35.101   luup.variable_set:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint was: EMPTY now: 18 #hooks:0
2021-05-11 10:05:35.102   luup.variable_set:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint was: EMPTY now: 18 #hooks:0
2021-05-11 10:05:35.102   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.TemperatureDevice was: EMPTY now: 0 #hooks:0
2021-05-11 10:05:35.103   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerURL was: EMPTY now: http:// #hooks:0
2021-05-11 10:05:35.103   luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerOffURL was: EMPTY now: http:// #hooks:0
2021-05-11 10:05:35.103   luup.attr_set:: 52.subcategory_num = 2
2021-05-11 10:05:35.106   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeTarget
2021-05-11 10:05:35.108   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeStatus
2021-05-11 10:05:35.111   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint
2021-05-11 10:05:35.113   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint
2021-05-11 10:05:35.116   luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature
2021-05-11 10:05:35.116   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.Configured was: 0 now: 1 #hooks:0
2021-05-11 10:05:35.116   luup.set_failure:: status = 0
2021-05-11 10:05:35.117   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2021-05-11 10:05:35.117   luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: EMPTY now: 0 #hooks:0
2021-05-11 10:05:35.117   openLuup.scheduler:: [52] VirtualHeater2 device startup completed: status=true, msg=Ready, name=VirtualDevices
2021-05-11 10:05:35.626   openLuup.server:: request completed (4456 bytes, 1 chunks, 8545 ms) tcp{client}: 0x20a2fc0
2021-05-11 10:05:35.714   openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=679125970&_=1620678904534 HTTP/1.1 tcp{client}: 0x20a2fc0
2021-05-11 10:05:36.145   openLuup.server:: request completed (764639 bytes, 48 chunks, 429 ms) tcp{client}: 0x20a2fc0
2021-05-11 10:05:38.584   openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=679159576&Timeout=60&MinimumDelay=1500&_=1620678904535 HTTP/1.1 tcp{client}: 0x20a2fc0
2021-05-11 10:05:41.932   openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1c6c030