Error in connection handler

Maybe you have a clue why this happens quite often.
Logger: websockets.server
Source: custom_components/ocpp/sensor.py:254
First occurred: 9:26:24 (42 occurrences)
Last logged: 9:51:27
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
    await self.ws_handler(self, path)
  File "/config/custom_components/ocpp/sensor.py", line 108, in on_connect
    await cp.start()
  File "/config/custom_components/ocpp/sensor.py", line 270, in start
    await asyncio.gather(super().start(), self.post_connect())
  File "/config/custom_components/ocpp/sensor.py", line 145, in post_connect
    await self.trigger_boot_notification()
  File "/config/custom_components/ocpp/sensor.py", line 177, in trigger_boot_notification
    resp = await self.call(req)
  File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
    await self._get_specific_response(call.unique_id,
  File "/config/custom_components/ocpp/sensor.py", line 254, in _get_specific_response
    resp = await super()._get_specific_response(unique_id, timeout)
  File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
    response = await asyncio.wait_for(self._response_queue.get(),
  File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

Used HA: Home Assistant 2021.3.4 (Home Assistant OS)
Used component: 35df000

It looks like sending the trigger_boot_notification to your charge point results in a drop in the connection, perhaps due to reboot. I think these messages should best be ignored, not sure how to suppress them to prevent them being logged.

Another improvement would be to send the trigger_boot_notification only on request, for instance by adding it as a service.
This would allow you to add a button to the ha dashboard that triggers the boot notification when pressed.

Funny thing is, the station just sits there. I was at work and the device should have been active all the time. But something is not quite right as it seems. Status active sometimes comes up, but most of the time it's on unknown state too. And... What is the trigger_boot_notification btw? ^^

The charge point sends a boot notification to the central system at boot, in order to register itself with the central server The central system  then responds with a confirmation.  The trigger boot notification kickstarts this registration process from the central server.

Here's example of a log when the boot notification is succesfully triggered:
2021-03-17 20:20:20 WARNING (MainThread) [homeassistant.loader] You are using a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-03-17 20:20:21 WARNING (MainThread) [homeassistant.loader] You are using a custom integration ocpp which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"d63f7e70-68e8-4cf3-ab3d-7dade9a7efc9","TriggerMessage",{"requestedMessage":"BootNotification"}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"d63f7e70-68e8-4cf3-ab3d-7dade9a7efc9",
{
"status": "Accepted"
}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"652b5206-14ef-4c10-895b-d234afb67d56","TriggerMessage",{"requestedMessage":"StatusNotification"}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"652b5206-14ef-4c10-895b-d234afb67d56",
{
"status": "Accepted"
}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"f15d531a-9e70-4793-a4a5-18f931d37dff","RemoteStopTransaction",{"transactionId":1234}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"f15d531a-9e70-4793-a4a5-18f931d37dff",
{
"status": "Rejected"
}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"aeaabe65-6b8c-45f4-a7db-29f907f39896","ChangeAvailability",{"connectorId":0,"type":"Operative"}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"aeaabe65-6b8c-45f4-a7db-29f907f39896",
{
"status": "Accepted"
}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"75e673b4-a80d-454e-ac99-bf37509d5d3d","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"75e673b4-a80d-454e-ac99-bf37509d5d3d",
{
"unknownKey": [],
"configurationKey": [
{
"readonly": false,
"key": "MeterValuesSampledData",
"value": "Current.Export,Current.Import,Current.Offered,Energy.Active.Export.Register,Energy.Active.Import.Register,Energy.Reactive.Export.Register,Energy.Reactive.Import.Register,Energy.Active.Export.Interval,Energy.Active.Import.Interval,Energy.Reactive.Export.Interval,Energy.Reactive.Import.Interval,Frequency,Heartbeat,Power.Active.Export,Power.Active.Import,Power.Factor,Power.Offered,Power.Reactive.Export,Power.Reactive.Import,RPM,SoC,Status,Temperature,Voltage"
}
]
}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"1c79b083-6c25-4c17-a8c0-a2286a3c7664","GetConfiguration",{"key":["MeterValueSampleInterval"]}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"1c79b083-6c25-4c17-a8c0-a2286a3c7664",
{
"unknownKey": [],
"configurationKey": [
{
"readonly": false,
"key": "MeterValueSampleInterval",
"value": "10"
}
]
}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: send [2,"8778c086-3358-4e3b-8f17-739e7c8d208a","RemoteStartTransaction",{"idTag":"ID4","connectorId":1,"chargingProfile":{"chargingProfileId":1,"stackLevel":999,"chargingProfileKind":"Relative","chargingProfilePurpose":"TxProfile","chargingSchedule":{"duration":36000,"chargingRateUnit":"W","chargingSchedulePeriod":[{"startPeriod":0,"limit":22000}]}}}]
2021-03-17 20:23:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [3,"8778c086-3358-4e3b-8f17-739e7c8d208a",
{
"status": "Accepted"
}]
2021-03-17 20:23:15 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1540383426","BootNotification",
{
"chargePointSerialNumber": "88034",
"chargePointVendor": "Wall Box Chargers",
"meterType": "Internal NON compliant",
"meterSerialNumber": "",
"chargePointModel": "PLP1-0-2-4",
"iccid": "",
"chargeBoxSerialNumber": "88034",
"firmwareVersion": "4.7.6",
"imsi": ""
}]
2021-03-17 20:23:15 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1540383426",{"currentTime":"2021-03-17T19:23:15.220260","interval":10,"status":"Accepted"}]
2021-03-17 20:23:15 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"35005211","StartTransaction",
{
"connectorId": 1,
"meterStart": 0,
"idTag": "ID4",
"timestamp": "2021-03-17T19:22:59Z"
}]
2021-03-17 20:23:15 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"35005211",{"transactionId":1234,"idTagInfo":{"status":"Accepted"}}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1726956429","StatusNotification",
{
"info": "",
"vendorId": "",
"vendorErrorCode": "",
"connectorId": 0,
"errorCode": "NoError",
"status": "Available",
"timestamp": "2021-03-17T19:23:15Z"
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1726956429",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"278722862","StatusNotification",
{
"info": "",
"vendorId": "",
"vendorErrorCode": "",
"connectorId": 1,
"errorCode": "NoError",
"status": "Charging",
"timestamp": "2021-03-17T19:23:15Z"
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"278722862",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"468703135","Heartbeat",
{
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"468703135",{"currentTime":"2021-03-17T19:23:16.088173"}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1315634022","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:13Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "34",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1315634022",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1125898167","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:13Z",
"sampledValue": [
{
"value": "34",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Clock",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 0,
"transactionId": 0
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1125898167",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"628175011","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:13Z",
"sampledValue": [
{
"value": "34",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Clock",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"628175011",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1653377373","StatusNotification",
{
"info": "",
"vendorId": "",
"vendorErrorCode": "",
"connectorId": 0,
"errorCode": "NoError",
"status": "Available",
"timestamp": "2021-03-17T19:23:16Z"
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1653377373",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"608413784","StatusNotification",
{
"info": "",
"vendorId": "",
"vendorErrorCode": "",
"connectorId": 1,
"errorCode": "NoError",
"status": "Charging",
"timestamp": "2021-03-17T19:23:16Z"
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"608413784",{}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1973594324","StatusNotification",
{
"info": "",
"vendorId": "",
"vendorErrorCode": "",
"connectorId": 1,
"errorCode": "NoError",
"status": "Charging",
"timestamp": "2021-03-17T19:23:16Z"
}]
2021-03-17 20:23:16 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1973594324",{}]
2021-03-17 20:23:27 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1129566413","Heartbeat",
{
}]
2021-03-17 20:23:27 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1129566413",{"currentTime":"2021-03-17T19:23:27.217407"}]
2021-03-17 20:23:27 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1424268980","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:26Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "64",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:23:27 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1424268980",{}]
2021-03-17 20:23:38 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"137806862","Heartbeat",
{
}]
2021-03-17 20:23:38 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"137806862",{"currentTime":"2021-03-17T19:23:38.331652"}]
2021-03-17 20:23:38 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"135497281","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:37Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "98",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:23:38 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"135497281",{}]
2021-03-17 20:23:49 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1937477084","Heartbeat",
{
}]
2021-03-17 20:23:49 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1937477084",{"currentTime":"2021-03-17T19:23:49.453802"}]
2021-03-17 20:23:49 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1159126505","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:48Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "132",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:23:49 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1159126505",{}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1100661313","Heartbeat",
{
}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1100661313",{"currentTime":"2021-03-17T19:24:00.602637"}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"84353895","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:59Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "165",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"84353895",{}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1998898814","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:59Z",
"sampledValue": [
{
"value": "165",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Clock",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 0,
"transactionId": 0
}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1998898814",{}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1585990364","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:23:59Z",
"sampledValue": [
{
"value": "165",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Clock",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:00 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1585990364",{}]
2021-03-17 20:24:11 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1477171087","Heartbeat",
{
}]
2021-03-17 20:24:11 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1477171087",{"currentTime":"2021-03-17T19:24:11.672944"}]
2021-03-17 20:24:11 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1889947178","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:24:11Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "199",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:11 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1889947178",{}]
2021-03-17 20:24:22 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"491705403","Heartbeat",
{
}]
2021-03-17 20:24:22 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"491705403",{"currentTime":"2021-03-17T19:24:22.793195"}]
2021-03-17 20:24:22 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1474612399","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:24:21Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "233",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:22 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1474612399",{}]
2021-03-17 20:24:33 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1411549676","Heartbeat",
{
}]
2021-03-17 20:24:33 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1411549676",{"currentTime":"2021-03-17T19:24:33.880487"}]
2021-03-17 20:24:33 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1984210012","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:24:32Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "266",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:33 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1984210012",{}]
2021-03-17 20:24:44 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"1469348094","Heartbeat",
{
}]
2021-03-17 20:24:44 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"1469348094",{"currentTime":"2021-03-17T19:24:44.996137"}]
2021-03-17 20:24:45 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"463480570","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:24:43Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "299",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:45 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"463480570",{}]
2021-03-17 20:24:56 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"317097467","Heartbeat",
{
}]
2021-03-17 20:24:56 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"317097467",{"currentTime":"2021-03-17T19:24:56.096082"}]
2021-03-17 20:24:56 INFO (MainThread) [ocpp] WallboxPulsar: receive message [2,"927612902","MeterValues",
{
"meterValue": [
{
"timestamp": "2021-03-17T19:24:54Z",
"sampledValue": [
{
"value": "2e+01",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"phase": "L1",
"measurand": "Current.Import",
"unit": "A"
},
{
"value": "32",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Current.Offered",
"unit": "A"
},
{
"value": "333",
"format": "Raw",
"location": "Outlet",
"context": "Sample.Periodic",
"measurand": "Energy.Active.Import.Register",
"unit": "Wh"
}
]
}
],
"connectorId": 1,
"transactionId": 1234
}]
2021-03-17 20:24:56 INFO (MainThread) [ocpp] WallboxPulsar: send [3,"927612902",{}]

Hmm, what do I have to do for these extended logs in the custom component? I guess right now I just get errors and nothing more. Maybe there is some stuff missing?

This should be enabled by default, it is in the ocpp/sensor.py:
_LOGGER = logging.getLogger(__name__)
logging.getLogger("ocpp").setLevel(logging.DEBUG)

The log messages are  added to the home_assistant.log file.

It's possible you configured the logger to suppress these messages. See https://www.home-assistant.io/integrations/logger/

i've updated to code to skip the trigger of boot notification. can you check if it helps?

Might be true... I changed it to:
logger:
  default: info
  logs:
    custom_components.ocpp: debug

Now I wait a bit for more information

The logging for HACS based integrations is actually controlled in a different way:
https://hacs.xyz/docs/basic/logs/

So more like that?
logger:
  default: info
  logs:
    custom_components.hacs: debug
    ocpp: debug

Honestly, I don't know for sure. I don't have any logger configuration in my configuration.yaml file.
I do have default_config: in there, that could set up some logging defaults.

I got this for you: https://gist.github.com/dreimer1986/b31ffdec9ab862ea9dd00506f67bb32b Quite long, so as GIST

Ok. Looks like home assistant never received a confirmation of the trigger boot notification. Maybe your charger goes into reboot immediately, without sending the confirmation. I can try to remove that trigger altogether, or maybe you can do this yourself. You you have the visual code plug-in installed, or do you have file access to the file system used by home assistant?

I have the file explorer addin up and running. So I can edit as you ask for.

Ok. Just remove the line
await self.trigger_boot_notification
In custom_components/ocpp/sensor.py
And restart HA

Seems like I got a special one here as I always seems to prefer... ^^
2021-03-17 21:31:13 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-03-17 21:31:13 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"d5079a8d-6c03-4b0f-a032-4ebe7ebad6fc","TriggerMessage",{"requestedMessage":"StatusNotification"}]
2021-03-17 21:31:14 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e52390-df13-411d-b782-739be3c33cab","BootNotification",{"chargePointVendor":"EV-BOX","chargePointModel":"G4-WIFI-F6017","chargePointSerialNumber":"20482857","firmwareVersion":"P0417B0417v0_785.200220_U6.0.0-050"}]
2021-03-17 21:31:14 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e52390-df13-411d-b782-739be3c33cab",{"currentTime":"2021-03-17T20:31:14.200482","interval":10,"status":"Accepted"}]
2021-03-17 21:31:14 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e52392-df13-451d-b782-739bf23bb6ac","StatusNotification",{"connectorId":0,"status":"Available","errorCode":"NoError","timestamp":"2021-03-17T20:31:14Z"}]
2021-03-17 21:31:14 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e52392-df13-451d-b782-739bf23bb6ac",{}]
2021-03-17 21:31:14 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e52392-df13-451d-b782-739b144d3bae","StatusNotification",{"connectorId":1,"status":"Available","errorCode":"NoError","timestamp":"2021-03-17T20:31:14Z"}]
2021-03-17 21:31:14 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e52392-df13-451d-b782-739b144d3bae",{}]
2021-03-17 21:31:19 INFO (MainThread) [hass_nabucasa.google_report_state] Connected
2021-03-17 21:31:23 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e5239c-df13-451d-b782-739bc33b26e4","Heartbeat",{}]
2021-03-17 21:31:23 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e5239c-df13-451d-b782-739bc33b26e4",{"currentTime":"2021-03-17T20:31:23.721565"}]
2021-03-17 21:31:33 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e523a5-df13-461d-b782-739b2111bc1f","Heartbeat",{}]
2021-03-17 21:31:33 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e523a5-df13-461d-b782-739b2111bc1f",{"currentTime":"2021-03-17T20:31:33.726689"}]
2021-03-17 21:31:43 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e523af-df13-461d-b782-739bb260595b","Heartbeat",{}]
2021-03-17 21:31:43 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e523af-df13-461d-b782-739bb260595b",{"currentTime":"2021-03-17T20:31:43.717205"}]
2021-03-17 21:31:43 ERROR (MainThread) [websockets.server] Error in connection handler
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
await self.ws_handler(self, path)
File "/config/custom_components/ocpp/sensor.py", line 110, in on_connect
await cp.start()
File "/config/custom_components/ocpp/sensor.py", line 275, in start
await asyncio.gather(super().start(), self.post_connect())
File "/config/custom_components/ocpp/sensor.py", line 147, in post_connect
await self.trigger_status_notification()
File "/config/custom_components/ocpp/sensor.py", line 171, in trigger_status_notification
resp = await self.call(req)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
await self._get_specific_response(call.unique_id,
File "/config/custom_components/ocpp/sensor.py", line 259, in _get_specific_response
resp = await super()._get_specific_response(unique_id, timeout)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
response = await asyncio.wait_for(self._response_queue.get(),
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError
2021-03-17 21:31:48 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-03-17 21:31:48 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"ef2fd0ed-b8a5-4070-a9ee-8f7d43105432","TriggerMessage",{"requestedMessage":"StatusNotification"}]
2021-03-17 21:31:53 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e523b9-df13-461d-b782-739b7c90f496","Heartbeat",{}]
2021-03-17 21:31:53 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e523b9-df13-461d-b782-739b7c90f496",{"currentTime":"2021-03-17T20:31:53.718608"}]
2021-03-17 21:32:03 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e523c3-df13-461d-b782-739baccd91d2","Heartbeat",{}]
2021-03-17 21:32:03 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e523c3-df13-461d-b782-739baccd91d2",{"currentTime":"2021-03-17T20:32:03.729934"}]
2021-03-17 21:32:13 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e523cd-df13-461d-b782-739b3677270e","Heartbeat",{}]
2021-03-17 21:32:13 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e523cd-df13-461d-b782-739b3677270e",{"currentTime":"2021-03-17T20:32:13.716836"}]
2021-03-17 21:32:18 ERROR (MainThread) [websockets.server] Error in connection handler
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
await self.ws_handler(self, path)
File "/config/custom_components/ocpp/sensor.py", line 110, in on_connect
await cp.start()
File "/config/custom_components/ocpp/sensor.py", line 275, in start
await asyncio.gather(super().start(), self.post_connect())
File "/config/custom_components/ocpp/sensor.py", line 147, in post_connect
await self.trigger_status_notification()
File "/config/custom_components/ocpp/sensor.py", line 171, in trigger_status_notification
resp = await self.call(req)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
await self._get_specific_response(call.unique_id,
File "/config/custom_components/ocpp/sensor.py", line 259, in _get_specific_response
resp = await super()._get_specific_response(unique_id, timeout)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
response = await asyncio.wait_for(self._response_queue.get(),
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError
2021-03-17 21:32:23 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-03-17 21:32:23 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"e504c4c4-48bc-4497-a7e9-6532f73a4008","TriggerMessage",{"requestedMessage":"StatusNotification"}]
2021-03-17 21:32:23 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e523d7-df13-461d-b782-739b2ad19a4a","Heartbeat",{}]
2021-03-17 21:32:23 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e523d7-df13-461d-b782-739b2ad19a4a",{"currentTime":"2021-03-17T20:32:23.867768"}]

After it now comlained about the next line, I commented that out too, then it complained about the one after that... Now I have commneted out the three await before sending configure and now it complains about this one.
2021-03-17 21:40:16 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-03-17 21:40:16 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"355a0e1c-82ce-4697-a7e1-de829767f30d","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2021-03-17 21:40:17 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525af-df13-411d-b782-739b743e82ab","BootNotification",{"chargePointVendor":"EV-BOX","chargePointModel":"G4-WIFI-F6017","chargePointSerialNumber":"20482857","firmwareVersion":"P0417B0417v0_785.200220_U6.0.0-050"}]
2021-03-17 21:40:17 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525af-df13-411d-b782-739b743e82ab",{"currentTime":"2021-03-17T20:40:17.124945","interval":10,"status":"Accepted"}]
2021-03-17 21:40:17 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525b1-df13-451d-b782-739bb637ecac","StatusNotification",{"connectorId":0,"status":"Available","errorCode":"NoError","timestamp":"2021-03-17T20:40:17Z"}]
2021-03-17 21:40:17 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525b1-df13-451d-b782-739bb637ecac",{}]
2021-03-17 21:40:17 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525b2-df13-451d-b782-739b99b471ae","StatusNotification",{"connectorId":1,"status":"Available","errorCode":"NoError","timestamp":"2021-03-17T20:40:17Z"}]
2021-03-17 21:40:17 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525b2-df13-451d-b782-739b99b471ae",{}]
2021-03-17 21:40:21 INFO (MainThread) [hass_nabucasa.google_report_state] Connected
2021-03-17 21:40:26 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525bb-df13-451d-b782-739b633426e4","Heartbeat",{}]
2021-03-17 21:40:26 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525bb-df13-451d-b782-739b633426e4",{"currentTime":"2021-03-17T20:40:26.621734"}]
2021-03-17 21:40:36 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525c4-df13-461d-b782-739b550dbc1f","Heartbeat",{}]
2021-03-17 21:40:36 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525c4-df13-461d-b782-739b550dbc1f",{"currentTime":"2021-03-17T20:40:36.618501"}]
2021-03-17 21:40:46 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525ce-df13-461d-b782-739b4864595b","Heartbeat",{}]
2021-03-17 21:40:46 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525ce-df13-461d-b782-739b4864595b",{"currentTime":"2021-03-17T20:40:46.616133"}]
2021-03-17 21:40:46 ERROR (MainThread) [websockets.server] Error in connection handler
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
await self.ws_handler(self, path)
File "/config/custom_components/ocpp/sensor.py", line 110, in on_connect
await cp.start()
File "/config/custom_components/ocpp/sensor.py", line 276, in start
await asyncio.gather(super().start(), self.post_connect())
File "/config/custom_components/ocpp/sensor.py", line 150, in post_connect
await self.configure(
File "/config/custom_components/ocpp/sensor.py", line 231, in configure
resp = await self.call(req)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
await self._get_specific_response(call.unique_id,
File "/config/custom_components/ocpp/sensor.py", line 260, in _get_specific_response
resp = await super()._get_specific_response(unique_id, timeout)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
response = await asyncio.wait_for(self._response_queue.get(),
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError
2021-03-17 21:40:51 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-03-17 21:40:51 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"ab711f8c-2579-4136-9177-1b785f221810","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2021-03-17 21:40:56 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525d8-df13-461d-b782-739b9597f496","Heartbeat",{}]
2021-03-17 21:40:56 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525d8-df13-461d-b782-739b9597f496",{"currentTime":"2021-03-17T20:40:56.618710"}]
2021-03-17 21:41:06 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525e2-df13-461d-b782-739b56d191d2","Heartbeat",{}]
2021-03-17 21:41:06 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525e2-df13-461d-b782-739b56d191d2",{"currentTime":"2021-03-17T20:41:06.618852"}]
2021-03-17 21:41:16 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525ec-df13-461d-b782-739b3772270e","Heartbeat",{}]
2021-03-17 21:41:16 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525ec-df13-461d-b782-739b3772270e",{"currentTime":"2021-03-17T20:41:16.615218"}]
2021-03-17 21:41:21 ERROR (MainThread) [websockets.server] Error in connection handler
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
await self.ws_handler(self, path)
File "/config/custom_components/ocpp/sensor.py", line 110, in on_connect
await cp.start()
File "/config/custom_components/ocpp/sensor.py", line 276, in start
await asyncio.gather(super().start(), self.post_connect())
File "/config/custom_components/ocpp/sensor.py", line 150, in post_connect
await self.configure(
File "/config/custom_components/ocpp/sensor.py", line 231, in configure
resp = await self.call(req)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
await self._get_specific_response(call.unique_id,
File "/config/custom_components/ocpp/sensor.py", line 260, in _get_specific_response
resp = await super()._get_specific_response(unique_id, timeout)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
response = await asyncio.wait_for(self._response_queue.get(),
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError
2021-03-17 21:41:26 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-03-17 21:41:26 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"516fbe89-6bb1-49ed-96a1-9ca9888bcec2","GetConfiguration",{"key":["MeterValuesSampledData"]}]
2021-03-17 21:41:26 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e525f6-df13-461d-b782-739b1ba0b94a","Heartbeat",{}]
2021-03-17 21:41:26 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e525f6-df13-461d-b782-739b1ba0b94a",{"currentTime":"2021-03-17T20:41:26.767930"}]
2021-03-17 21:41:36 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e52600-df13-461d-b782-739b91336085","Heartbeat",{}]
2021-03-17 21:41:36 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e52600-df13-461d-b782-739b91336085",{"currentTime":"2021-03-17T20:41:36.617765"}]
2021-03-17 21:41:46 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e5260a-df13-461d-b782-739bd86dfdc0","Heartbeat",{}]
2021-03-17 21:41:46 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e5260a-df13-461d-b782-739bd86dfdc0",{"currentTime":"2021-03-17T20:41:46.620947"}]
2021-03-17 21:41:56 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: receive message [2,"27e52614-df13-461d-b782-739b530893fc","Heartbeat",{}]
2021-03-17 21:41:56 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [3,"27e52614-df13-461d-b782-739b530893fc",{"currentTime":"2021-03-17T20:41:56.616950"}]
2021-03-17 21:41:56 ERROR (MainThread) [websockets.server] Error in connection handler
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
await self.ws_handler(self, path)
File "/config/custom_components/ocpp/sensor.py", line 110, in on_connect
await cp.start()
File "/config/custom_components/ocpp/sensor.py", line 276, in start
await asyncio.gather(super().start(), self.post_connect())
File "/config/custom_components/ocpp/sensor.py", line 150, in post_connect
await self.configure(
File "/config/custom_components/ocpp/sensor.py", line 231, in configure
resp = await self.call(req)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
await self._get_specific_response(call.unique_id,
File "/config/custom_components/ocpp/sensor.py", line 260, in _get_specific_response
resp = await super()._get_specific_response(unique_id, timeout)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
response = await asyncio.wait_for(self._response_queue.get(),
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

For me it seems almost like whatever we pass, it hates what it gets.

Yes, looks like it. Have you tried rebooting your charge point, and then home assistant?

and is your charge point really OCPP 1.6 compliant?

It claims to be. We even had that support as reason to buy. https://evbox.com/en/products/home-chargers/elvi Check certifications. In tech specs we have: OCPP 1.5 S and 1.6 J. Trying the reboot now.

and they are celebrating their certification here: https://news.evbox.com/nl-NL/184402-evbox-is-eerste-ocpp-1-6-gecertificeerde-partner-wereldwijd-door-open-charge-alliance

Yeah. Btw, I rebooted the wallbox and had a HassOS reboot parallel to it. HA was back on after the box. Results: No change at all.
OK, before we go crazy here, I call the support tomorrow. They say no support for custom OCPP solutions, but I will ask if the firmware installed is up to date. The app always says "unknown version" and that is strange. Rest of the app works fine though. We did set up the whole thing that way.
What makes me wonder a bit is that: https://webcache.googleusercontent.com/search?q=cache:vLRnn2gId0UJ:https://intercom.help/true-energy-8e0af048b9de/en/articles/4886123-evbox+&cd=3&hl=de&ct=clnk&gl=de This is a older cached version of a manual set up how to of a  OCPP server provider by now officially supported by EVBOX. Why that special /evbox/ at the end of the url? Why do they need the serial? Some login needed or what?

yes, there is a login / authentication scheme.  See section 3.1.1 of the specification:
ocpp-j-1.6-specification.pdf

And 6.2.2 tells something about a key needed for authentication... I got that EVB... chargepoint ID which seems to be already known AND I have a 10 digit security code. Both were on a sticker. Maybe thats the problem? I need the key for Install mode in app too btw aka for changing the OCPP server, activating WIFI etc. Well Well, at least I already got the firmware version out of it thx to the addin. Now I can go ask whats maybe wrong.

In OCPP the charge point authenticates to the central system. There is no mechanism for the central system to authenticate to the charge point.

So, had a nice chat with the EVBOX hotline. Somehow changing the OCPP from Everon (default) to something else kills... almost everything. So... we have to wait for a update. The box right now never leaves the Everon service at all. Regardless what you do. And the settings on Everon are completely randomized after trying to. Somehow the Box now had 2 charge connectors and was always charging O_o. OK, thanks for the support. For now we have to wait.

Ok, good to know. Are you paying a monthly fee currently? I can imagine vendors that charge such a fee would not like you to leave, and using OCPP would enable you to do exactly that.

Nope, all free. Lets see and wait ^^ I did set up the box again now and they are releasing a new firmware next week they said.

Still no update. As the problem is the wallbox and not your solution, I will for now close this report.

2021-06-16 18:23:41 INFO (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 connected.
2021-06-16 18:23:41 INFO (MainThread) [ocpp] http://<IP_ADDRESS>:9000/EVB-P20482857: send [2,"230ed1aa-52de-4bfd-a2d0-4c9642179f3c","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]
2021-06-16 18:24:11 ERROR (MainThread) [websockets.server] Error in connection handler
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/websockets/server.py", line 191, in handler
await self.ws_handler(self, path)
File "/config/custom_components/ocpp/sensor.py", line 175, in on_connect
self._cp_metrics = await cp.start()
File "/config/custom_components/ocpp/sensor.py", line 388, in start
await asyncio.gather(super().start(), self.post_connect())
File "/config/custom_components/ocpp/sensor.py", line 214, in post_connect
await self.get_supported_features()
File "/config/custom_components/ocpp/sensor.py", line 238, in get_supported_features
resp = await self.call(req)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 264, in call
await self._get_specific_response(call.unique_id,
File "/config/custom_components/ocpp/sensor.py", line 371, in _get_specific_response
resp = await super()._get_specific_response(unique_id, timeout)
File "/usr/local/lib/python3.8/site-packages/ocpp/charge_point.py", line 292, in _get_specific_response
response = await asyncio.wait_for(self._response_queue.get(),
File "/usr/local/lib/python3.8/asyncio/tasks.py", line 501, in wait_for
raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError
2021-06-16 18:24:16 DEBUG (MainThread) [custom_components.ocpp.sensor] Charger http://<IP_ADDRESS>:9000/EVB-P20482857 reconnected.

Finally new firmware. Sadly it seems like this box does not wanna be used away from their supported charge management sites...
Tested with c84ff1f but with reverted 893f15f as it causes HA to not restart anymore due to syntax errors.

It should not be reporting http:// in the log as this is the wrong protocol it should be ws:// try updating your ocpp url to either ws://<IP_ADDRESS>:9000 or simply <IP_ADDRESS>:9000

Well, it is ws://<IP_ADDRESS>:9000/ Will verify later at home again, but I am only able to use ws:// in that charger.

You can also use Wireshark to verify the initial websocket handshake is conforming to the ocpp specification. It won't show in the HA log.

A charger that has connected correctly to the websocket server should report Charger EVB-P20482857 connected

Will create some Wireshark logs from my network with the default Online OCPP target it uses and with the correct ws:// target later today. Maybe we can find out a few things that way. They claim to be OCPP supportive and even celebrated that confirmed conformity last year. (See Mar 17th discussion in here) Firmware is the newest right now.

WS Logs.zip
Here war are.
Timestamp 1857 goes from <IP_ADDRESS> to evbox.everon.io and works.
Timestamp 1916 goes from <IP_ADDRESS> to <IP_ADDRESS>:9000 and does not work.
I have zero clue about this stuff, but if I see things somehow right in there it first sends infomration about supported OCPP and some Token stuff to the addin and then the addin answers that it's not valid http request?

Afraid I can't help with websockets. Wikipedia has details on the handshake and standards the client should adhere to https://en.m.wikipedia.org/wiki/WebSocket

Well, maybe someone else already tinkered with it. I can only show what my box does and that it claims to have OCPP 1.6 in that http packets. I leave that here for others to confirm it or confirm that the box is not OCPP 1.6 supportive at all as it does stupid things instead of the way it should go.

I don't even know what SOAP is ^^ But yes... maybe.

https://www.educba.com/json-vs-soap/

Well, if that is the case then the everon logs should contain SOAP protocol data passing around ...

@dreimer1986, I see a TLSv1.2 request being made by your charge point to port 9000. Could that be related to the connection issue? I don't think the occp server currently supports TLS

I used ws:// and not wss:// so I think not, buuuut I would say this special case of a charge station could do it anyways? When I try wss:// nothing seems to happen at all.

I'm guessing it is something in the chargers config, can you screenshot it?

 There is only support for their included list of providers. As these work, noone will help me at all. The config app even shows a full screen message telling me that there is zero support for not supported solutions whenever I enter a custom ws:// or wss:// url. So that will not help us at all... Last time I tried to find something out they just told me that IN THEORY all OCPP 1.6 supporting solutions do work, but they only support the ones they tested and the rest is up to the user if it does anything. So for me it looks like it does some special things still sort of fine in the protocol, but not yet in the addin? I got to that assumption as you are talking about not working TLS and SOAP. Maybe I am wrong though ^^

@dreimer1986 Did you retry the new version of this integration maybe in the meantime something got fixed?
Please remove the config from you config file and install the integration though the UI (see updated readme for info)

Already reconfigured it, but not yet tested it. Right now I have my car on it charging from 10%, so I could try tomorrow.

Sooo, tested it. Still not much coming from the device. Only thing which has information is charger.ID. There you can read http://<IP_ADDRESS>:9000/EVB-P20482857 I tried to open that link in a browser as http looks strange and got this:
Failed to open a WebSocket connection: invalid Connection header: keep-alive.

You cannot access a WebSocket server directly with a browser. You need a WebSocket client.

Rest all the same. I added all checkboxes on installing and all stuff it passes on is shown on my testing site. Only this one does show anything. I am quite sure that as the behavior is the same as before that the dumps don't need an update. What about this one? https://github.com/lbbrhzn/ocpp/issues/55 Didn't you say that it seems like my box wants to open a secured connection maybe?

@dreimer1986, looks like your charger is trying to connect to your home assistant server (IP <IP_ADDRESS>) on port 9000, with charger id EVB-P20482857. The OCPP integration is listening to <IP_ADDRESS>:9000, and indeed it is a websocket that is not meant to be opened directly  from a browser.
Can you try to grab the communication using wireshark again?

Attached a few new ones. IP of HA is <IP_ADDRESS>, IP of the charger is <IP_ADDRESS>. Just for fun I redid the same with a external forwarding to be 100% sure as this must be the correct IP as all my HA hosted stuff is running over this one either. Of course I used ws:// aka insecure.
WS Logs NEW.zip

@dreimer1986, I finally got around to take a look at your logs. I see a lot of strange TCP packets (TCP Out-Of_order, TCP Dup Ack, TCP Retransmission] from charger to HA
There are some packets coming through though:
From Charger to HA:
GET http://<IP_ADDRESS>:9000/EVB-P20482857 HTTP/1.1\r\n

Response:
Hypertext Transfer Protocol
    HTTP/1.1 101 Switching Protocols\r\n
    Upgrade: websocket\r\n
    Connection: Upgrade\r\n
    Sec-WebSocket-Accept: KJsG7JYcfQ2KBj3nLE62483cGH0=\r\n
    Date: Tue, 24 Aug 2021 17:09:03 GMT\r\n
    Server: Python/3.9 websockets/9.1\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.007920000 seconds]
    [Request in frame: 4696]
    [Request URI: http://<IP_ADDRESS>:9000/EVB-P20482857]

Followed by a Websocket packet from HA to charger:
Line-based text data (1 lines)
    [2,"368f39ff-02e5-4514-8636-ec4dc6cc5f66","GetConfiguration",{"key":["SupportedFeatureProfiles"]}]

This response is acknowledged on TCP level, but there is no response from the charger.
This pattern is repeated over and over again. So it looks like the charger does not respond the GetConfiguration command.

On the ext logs, the pattern is the same, only withouth the ACKs

Network is A-OK. I can sort of guarantee that as it's my job to make these for customers and hopefully I know what I am doing there :P WIFI is a bit on the weaker side though as the way to the box is a lil longer, maybe that's the problem here. But as you said it seems to dislike something regarding the connection being accepted. Maybe the older logs where I left the configuration on Everon service are of any help? It communicates fine with that service as it's the one maintained by EVBOX.

Stupid question, what does "db dogs in spa" mean?
Any need for a few more logs/dumps/anything?

it appears i accidentally created a milestone by typing in the wrong window

This is the response from the Everon server:
``
Hypertext Transfer Protocol
HTTP/1.1 101 Switching Protocols\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 101 Switching Protocols\r\n]
Response Version: HTTP/1.1
Status Code: 101
[Status Code Description: Switching Protocols]
Response Phrase: Switching Protocols
Date: Thu, 17 Jun 2021 16:58:56 GMT\r\n
Connection: upgrade\r\n
Set-Cookie: ISESSIONID=node01ff5d7ai56yujwue9t38xir3g25516.node0; Path=/\r\n
Expires: Thu, 01 Jan 1970 00:00:00 GMT\r\n
Sec-WebSocket-Protocol: ocpp1.6\r\n
Sec-WebSocket-Accept: 7dsHRS6AgV6wWNgNayVVCKVwoK8=\r\n
Upgrade: WebSocket\r\n
traceId: 45a607a8547869c8aaf22cdd3ee1df3d\r\n
Via: 1.1 google\r\n
CF-Cache-Status: DYNAMIC\r\n
cf-request-id: 0abc82696f0000d7295d9d9000000001\r\n
Server: cloudflare\r\n
CF-RAY: 660dd35578d0d729-FRA\r\n
\r\n
[HTTP response 1/1]

The Everon server also sends:
z[3,"285e3bcd-df13-411d-b782-469b2324a9b2",{"status":"Accepted","currentTime":"2021-06-17T16:58:56.828Z","interval":86400}]

Your wireshark traces seems to be missing some packets. I guess you are capturing by sniffing the Wifi?
Maybe you can capture on your router or switch instead.

That's what I did. I can do so on my router. It's the same brand and has the same features. Trying to minimize the network today evening and create Everon and OCPP addin sniff logs.

OK, I have three logs for everything internet related. All three are here. I tried to remove a few devices to make the logs smaller. Of course this is ONLY the Everon communication as there is no external communication to the addin right now. I don't think that a internal sniff from the router is of any help as my LAN is switch and not hub based. Thus the internal communication is never even reaching it. Switches are non managed though, so no logging here too... If you need something else, tell me. I very likely can get the stuff needed from my work place, just not today and not without more information what you might need. So for now... I hope this is what you were asking for ^^
Everon Logs.zip

I know I might go on your nerves by now, but one thing I just realized when I myself was curious about the logs: Port 80 and http://everon.io/ocpp/ means we have no encryption at all, right? If so, something fishy is happening inside the insanity of my box. Like it expects something it does not get yet or maybe some timeout somewhere?

OK, this is worth a new entry and no Edit ^^ Tested the new version...
Here a few pics and a new log of the current progress. YES I INDEED SAID PROGRESS!!! :D
But two exceptions are now showing up here. See log. This time 100% unfiltered!
home-assistant (1).log

well, at least it is dping something. Finally!

P.S. Thanks for all the work you all put into this addon. :D

New Log with the two new pull requests added:
home-assistant.log

The timeout error should not affect the functionality, looks like a race condition was happening with the boot notification (anything received before it is sent is discarded by the charger). PR #164 should fix it.

OK, added too. New small log of restarted HA looks great:
home-assistant new.log
Before that I realized that the Addin aka my Charger was Offline anyways. The monster Log here:
home-assistant.log

@dreimer1986 check v0.3.15. data types, units and device class have been updated for the sensors.

@lbbrhzn yes, I actively followed your PR. Sadly nothing really changed.

These can be sort of fixed by adding these to customize.yaml:
sensor.charger_config_response:
  device_class: timestamp
sensor.charger_heartbeat:
  device_class: timestamp

The diagram still is wrong, but then the timestamp is interpreted and I get a reply like "5 minutes ago".

I could add more, but all behave that way. I'd expect something like this instead:

This is the official Shelly integration

Official FritzBox integration

Unofficial PSA API integration by flobz

@dreimer1986 sensor state_class was improved in @dreimer1986, please check the diagrams again.

@dreimer1986 extracting the charge point identity identity from connection URL was improved in v0.3.17, please check if it solves your error.

OK, lets see. First, renaming was the trick. It looks way better now. Some things are perfect, some are not yet. I can't test all of the values though as my box sends zero information about power incoming or outgoing at all and that's no bug on your side, but a flaw of the box itself. Sad, but true...
switch.wallbox_availability: Looks fine
switch.wallbox_charge_control: Way better now. "Failed with response: Rejected" But that could be fine as I am not charging right now.
sensor.wallbox_config_response: Something not 100% OK yet. Compare with Heartbeat below then

sensor.wallbox_connectors: Looks fine
sensor.wallbox_data_response: Always unknown here. Looks fine though.
sensor.wallbox_energy_active_import_register: Always unknown here. Looks fine though.
sensor.wallbox_error_code: Looks fine
sensor.wallbox_features: Looks fine
sensor.wallbox_fw_status: Always unknown here. Looks fine though.
sensor.wallbox_fw_version: Looks fine after a reset of the box and then sooner or later falls to unknown. Maybe save the value? Funfact, it was unknown a few secs before that image and the reset I made by addin and still the log looks like this:

sensor.wallbox_heartbeat: This is what I mean. Heartbeat interprets the timecode, config_response does not. Looks fine though:

sensor.wallbox_id: Looks fine after a reset of the box and then sooner or later falls to unknown. Maybe save the value? Funfact, it was unknown a few secs before that image and the reset I made by addin and still the log looks like this:

number.wallbox_maximum_current: Impossible with my box? "Failed with response: Rejected" Looks fine though.
sensor.wallbox_meter_start: Always unknown. Looks fine though.
sensor.wallbox_model: Looks fine after a reset of the box and then sooner or later falls to unknown. Maybe save the value? Funfact, it was unknown a few secs before that image and the reset I made by addin and still the log looks like this:

sensor.wallbox_reconnects: Looks fine
switch.wallbox_reset: Works fine
sensor.wallbox_serial: Looks fine after a reset of the box and then sooner or later falls to unknown. Maybe save the value? Funfact, it was unknown a few secs before that image and the reset I made by addin and still the log looks like the others above with that behavior.
sensor.wallbox_session_energy: Impossible with my box. Looks fine though.
sensor.wallbox_session_time: Looks fine
sensor.wallbox_status: Looks fine
sensor.wallbox_stop_reason: Looks fine
sensor.wallbox_transaction_id: Looks fine
switch.wallbox_unlock: "Failed with response: NotSupported" Looks fine though.
sensor.wallbox_vendor: Looks fine after a reset of the box and then sooner or later falls to unknown. Maybe save the value? Funfact, it was unknown a few secs before that image and the reset I made by addin and still the log looks like this:

The values retrieved from the chargers are actually saved and cached in memory. However, if the charger drops the connection, then the senor values are marked as 'unavailable'. You should be able to see this in your log (Charger  disconnected from :.)

Indeed that's the case. Wonderful :D
So last thing I can see as incorrect are the mentioned two and then we finally can close that bug I opened and in the end even extended/abused for more stuff. ^^
sensor.wallbox_config_response: Date Code not interpreted on Lovelace, but Diagram is fine.
sensor.wallbox_heartbeat: Date Code interpreted on Lovelace, but Diagram still wrong.

i addded a PR for handling the timestamps

Confirmed. All perfect. Thanks for all the work :D


About the description/note to outdated non-ARM/legacy/classic storage account

The nature of this issue is not limited to this page. It is the inquiry of the standard to deal the possible outdated info, which should exist in many pages/documents.
Please be aware: the answer to this issue has to be affirmative. Because this issue will be referred in future PRs as the reason to change the page.
For example, in this page, there is a statement as below:
This property is available for all storage accounts that are created with the Azure Resource Manager deployment model. For more information, see Storage account overview.
(Ref: https://learn.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent?tabs=portal#set-the-storage-accounts-allowblobpublicaccess-property-to-false)
Ofc the classic storage account is under retiring process, and it will be retired on 31 August 2024.
Hence, the statement like the example should relatively changed since legacy/classic storage account will no longer be used. I remember that the like-so statement appears in multiple documents/pages, and I cannot list them all here.
So, I want to ask about the standard of handling/editing the statement like this. Should editor:

delete the ARM word itself from the similar statement,
or use the important or note block to remind the reader that "classic storage account is no longer for use and you don't need to worry about it. If you are still using it, you should migrate it as soon as possible".

I believe this kind of change is necessary as the product itself is updating from time to time. If we still state that "only ARM product is feasible to what option", this may confuse the reader and increase the time costs to learn Azure product's concepts on an outdated product/concept.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 19c5587d-a2de-2dd7-679e-14c2a0eaa4a8
Version Independent ID: 8ee6091f-9c91-9dcd-6a0b-7b295fddd5d2
Content: Remediate anonymous public read access to blob data (Azure Resource Manager deployments) - Azure Storage
Content Source: articles/storage/blobs/anonymous-read-access-prevent.md
Service: azure-storage
GitHub Login: @akashdubey-ms
Microsoft Alias: akashdubey

@JoeyC-Dev
Thanks for your feedback! We will investigate and update as appropriate.

@JoeyC-Dev
Thank you for bringing this to our attention.
I've delegated this to content author @akashdubey-ms, who will review it and offer their insightful opinions.

#reassign:@pauljewellmsft

@JoeyC-Dev Thanks so much for your feedback. The article has been updated to remove the explicit mention that the property applies to accounts created with the ARM deployment model.
Given the fact that we already have separate articles around anonymous access remediation for classic deployments and ARM deployments, the additional phrase seems redundant and unnecessary, and, as you said, could potentially be confusing. Also, the article already calls out classic account retirement and recommends migration, so I think we're fine there.
Thanks again for bringing this up. The changes should go live later today. Closing the issue for now, but feel free to add comments, if needed.
#please-close


enable GIN mTLS support

pull request for https://github.com/malwaredllc/minicache/issues/6

@alvinlee001 nice! can we make the client_auth option more general, so it applies to all TLS (not just client side auth)?

Hi @malwaredllc, are u saying that you just want it to be https disabled or enabled? If https enabled, implies opting for mTLS? What about opting for TLS but not mTLS? It totally depends on you, but right now TLS is mandatory, while mTLS is optional.

@alvinlee001 Basically TLS should be optional. The problem I want to solve is that right now, if a server's hostname or IP does not appear in this TLS certificate config file here, then it will be unable to communicate with other servers.
This means that unless all of your servers are in the same subdomain that you can use a wildcard for (i.e. *.example.com), then if you want to add a new server, you must add its hostname/IP to that config file and run the ./gen.sh script to regenerate the TLS certificates, which is not ideal.
For example, if I want to add cacheserver4 to my docker-compose.yml to spin up an extra server in a container, I will need to add DNS:cacheserver4 to the certs/server-ext.cnf and regenerate the certificates first.
One way around this is to simply not use TLS (make it optional) to not have to worry about this, so the cluster size can dynamically change without issue. Alternatively, I need to figure out a more flexible way of doing TLS.

I see, @malwaredllc can we have an additional property called enable-tls and this will control whether we want to enable or disable HTTPS? So we can do it as separate from forcing mTLS, is that okay?

@alvinlee001 Yeah I think https-enabled sounds great

Hi @malwaredllc, i have implemented it. There will be a flag in CLI and json to specify if https should be enabled, it is enabled by default unless specified otherwise. I have pushed the new commit, kindly have a look.

@alvinlee001 thanks for your help with this, looks like the build is failing though (see checks above), can you take a look?

Ok wait

Hi @malwaredllc , sorry I have force pushed again, missed some changes previously. Now the tests are passing.

@alvinlee001 Looks good! Last thing will be to add a test to make sure that HTTP without TLS works properly (you can basically copy/paste this test in main_test.go but tweak the params to not use HTTPS.  Note you may need to modify this function to accept the https_enabled flag to do this.

Alright, sure @malwaredllc

hi @malwaredllc , added test and it is passing, previously has been testing the HTTP rest locally as well, it is working

@alvinlee001 looks awesome thanks for doing that! I left a couple of comments on small things to address above but besides that it looks ready to go

Hi @malwaredllc , I resolved the 2 comments just now, and pushed changes. pls have a look

@alvinlee001 after further investigation, it appears the integration tests are passing but they shouldn't be (see here: https://github.com/malwaredllc/minicache/runs/6465112038?check_suite_focus=true#step:8:33) - it is unable to connect to any nodes now, it visits them all then loops forever because it is skipping visited nodes - we can fix this test but still the main issue is that the connections to the server are failing

I am fixing the issue causing the test to appear to pass here and will merge it momentarily

@alvinlee001 ok I fixed the issue causing the test to appear to pass when it should fail. You can merge in the latest changes from the main branch

Hi @malwaredllc , sorry for the late reply, I was busy with my day job. I tried to find the issue with my code, which I think there are a few, and fixed them... but the tests still fail. However, if I run each of the tests individually by commenting out the others, all tests pass... I am not sure why though.

@alvinlee001 No worries, if you look at the test output here you'lll see the test failing is Test10kConcurrentRestApiPutsInsecure and the error message is:
2022/05/17 17:00:22 GetLeader failed rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: tls: first record does not look like a TLS handshake"...
So this indicates either the client or server is still trying to use TLS, but one side isn't.

I added a print statement which revealed "enable_https" and "enable_client_auth" are both set to true in the test Test10kConcurrentRestApiPutsInsecure, which should not be the case.
2022/05/17 11:17:34 enable https: %!b(bool=true), insecure: %!b(bool=true), client_auth: %!b(bool=true)

I figured out the problem, the StartClusterConfigWatcher goroutine has no shutdown mechanism, so the goroutine from the first test was interferring with the 2nd test. That is why if you run the 2nd test individually it works, but all tests won't work.
I am fixing it now and will push changes to your branch here.

@alvinlee001 I'm not able to modify your PR directly so I made a PR with your changes + the fix I added: https://github.com/malwaredllc/minicache/pull/9
Either you can copy over the changes to your branch and we can merge it (so you get credit for your contribution), or we can merge that PR.

Merged! Thanks for the contribution, feel free to add any ideas for other features or improvements

I also just updated the setup/usage information in the readme to include these new changes: https://github.com/malwaredllc/minicache#set-up-and-usage


Speech slows down when using espeak

The speech gets slower and slower when espeak is used and the MathCAT rate is set to be slower than regular speech. There is no problem with other speech synthesizers.
Details of the bug can be found in https://github.com/nvaccess/nvda/issues/15221.

This is exactly the bug I was referring to. Is your understanding that this bug has been patched and is no longer experienced by a user? If so, I think I still face it.

I thought it was fixed. It didn't happen to me in all the testing I did for
the other bug. Is the other bug fixed? Do you have a reproducible example
for this bug?
On Tue, Oct 31, 2023, 8:50 AM bhavyashah @.***> wrote:

This is exactly the bug I was referring to. Is your understanding that
this bug has been patched and is no longer experienced by a user? If so, I
think I still face it.
—
Reply to this email directly, view it on GitHub
https://github.com/NSoiffer/MathCATForPython/issues/51#issuecomment-1787495439,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALZM3FKQOWGFGQV37JQYXDYCEM4ZAVCNFSM6AAAAAA25NM4QKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBXGQ4TKNBTHE
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

In my limited testing with the new build, cutoffs are fixed and slowdowns are not (they may have worsened). ESpeak-NG at 35% with rate boost enabled and relative speech rate at 60. Variant Steph and language set to British English and NVDA version 2023.3 if that matters. Some examples below:
$X_1, X_2, \ldots, X_n$
$Y_n=\max \left{X_1, \ldots, X_n\right}$
$E\left(Y_{\mathrm{n}}\right)$
$P(0.1<\bar{X}<0.2)$
By "worsened", I feel like the slowing down begins sooner in the Math expression than in the previous build. I may be imagining this difference too so don't quote me on this.


Automatically size images if no size is specified in the style property

This is a feature request for <Image source={require('image!a.png')} /> to display the image even though there is no style property that specifies the size. For static images, the packager can compute the size of the image up front (and with a module like sharp, 2x-resolution images could be automatically generated from 3x ones when necessary).
For non-static images, I think the right thing is to resize the Image component after the image size is known, but to warn about the potentially janky user experience and extra reflow pass. So - basically like web but with warnings about suboptimal practices.

The problem with image sizing is that it's not trivial to know from an arbitrary URL what the size is. So, if you give the developer a way to get away with not knowing the size, by paying the cost of a reflow, he will take it in a whim (my long experience in the fb codebase).

Then, once you have an entire codebase that has no idea what sizes the images it display are, but sometimes you do need to know them, you are screwed. You add all sorts of hacks, threading them down, having all sorts of heuristics to figure them out, parsing the URI attempting to recover it...

What you need is to ask the image size when you get the URI, and then always keep this metadata around. By forcing the developer to know the image size to render it, I hope that it's going to lead them to fall into the pit of success by implementing that pattern by themselves. While this is a pretty sneaky technique, this is the best I got.

@vjeux i also thought this was a little annoying but after reading that explanation i can totally understand where you're coming from. I've seen many people add 500x500 images and then resize them to 50x50 through the interwebs. It also encourages like you said creating design patterns.. I could have a Icon react class which sets default width and height to 50px as well as other properties and i can specify other props like rightCorner, leftCorner etc.

This is happening now with static images. To summarize the above: core will not include any auto-sizing of network images, but feel free to develop and publish a module to take care of this if you would like to see it :smile:


updated GetConnectedDevices() example to utilize subscribe

References #276
updates specific example to be more exact for RX newbies

Thanks for the PR


Update basic.md

Description

Urgency

[ ] Blocker
[ ] High
[ ] Medium

Requirements

Test all commands and procedures.
Build content locally and test for formatting/links.
Add redirects to dcos-website/redirect-files.
Change all affected versions (e.g. 1.7, 1.8, and 1.9).
See the contribution guidelines.

It would be great to have a 1.8 stable channel, so we do not have to change...


Do less.

Don't do error when no error.
Don't do HOME when XDG_CONFIG_HOME.

@et342 but why? All of that happens only once during the whole life time of the application. Doesn't really look like a huge performance improvement. Unless I'm missing something? :thinking:

@rexim True. There is probably no actual perf hit. On the other hand, config-parsing code spends time on allocating, formatting and deallocating strings when there is absolutely no need to. Same goes for env lookup. IDK it just didn't felt right.


invalid parameter: no_build_server

Hi,
Im having trouble passing options to protoc-gen-tonic:
❯ protoc  --tonic_out=rpc --tonic_opt=no_build_server test.proto
--tonic_out: invalid parameter: no_build_server

Im also having the same trouble with protoc-gen-prost: https://github.com/Tuetuopay/protoc-gen-prost/issues/3
(im on a macbook with apple silicon processor, and using zsh)

Hi, sorry for the late response.
How did you install the plugin? If through crates.io, they you're likely not using this one but the one over at https://github.com/neoeinstein/protoc-gen-prost. His is the one published on crates.io, while mine was developed in parallel and did not end up being released anywhere.


Unable to build Toybox with Android NDK

I followed instructions for building Toybox with Android NDK.
The newest version I was able to build with NDK (21-25 with API 29-33) was 0.8.7.
Strangely 0.8.5 wouldn't build while 0.8.4 and 0.8.3 did just fine.
Anyone had better luck?
This what I used to build it:
#!/bin/sh -x

#unzip android-ndk-r25c-linux-x86_64.zip
NDK_TC_DIR=~/Android/Sdk/ndk/25.2.9519653/toolchains/llvm/prebuilt/linux-x86_64/bin
NDK_TC=aarch64-linux-android-

cd ${NDK_TC_DIR}
test -f ${NDK_TC}cc || ln -s aarch64-linux-android33-clang ${NDK_TC}cc
test -f ${NDK_TC}strip || ln -s llvm-objcopy ${NDK_TC}strip
cd -

export PATH="${NDK_TC_DIR}:$PATH"

make distclean
make LDFLAGS=--static CROSS_COMPILE=${NDK_TC} defconfig toybox

Below is the failed build output of 0.8.9 (0.8.5+ fail with similar errors):
+ make distclean
cleaned
root cleaned
removed .config
+ make LDFLAGS=--static CROSS_COMPILE=aarch64-linux-android- defconfig toybox
cc -o kconfig/conf kconfig/conf.c kconfig/zconf.tab.c -DKBUILD_NO_NLS=1 \
	-DPROJECT_NAME=\"ToyBox\"
In file included from kconfig/zconf.tab.c:2340:
kconfig/confdata.c: In function ‘conf_write’:
kconfig/confdata.c:435:34: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 128 [-Wformat-overflow=]
  435 |                 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
      |                                  ^~~~~~~~~~~~~~~~~
kconfig/confdata.c:435:17: note: ‘sprintf’ output between 13 and 150 bytes into a destination of size 128
  435 |                 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scripts/genconfig.sh
kconfig/conf -D /dev/null Config.in > /dev/null
scripts/make.sh
Library probe
generated/{Config.in,newtoys.h,flags.h,globals.h,tags.h,help.h}
Compile toybox
..........................toys/lsb/passwd.c:71:45: error: implicit declaration of function 'getspnam' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
  if (*(pass = pw->pw_passwd)=='x' && (sp = getspnam(name))) pass = sp->sp_pwdp;
                                            ^
toys/lsb/passwd.c:71:43: warning: incompatible integer to pointer conversion assigning to 'struct spwd *' from 'int' [-Wint-conversion]
  if (*(pass = pw->pw_passwd)=='x' && (sp = getspnam(name))) pass = sp->sp_pwdp;
                                          ^ ~~~~~~~~~~~~~~
toys/lsb/passwd.c:71:71: error: incomplete definition of type 'struct spwd'
  if (*(pass = pw->pw_passwd)=='x' && (sp = getspnam(name))) pass = sp->sp_pwdp;
                                                                    ~~^
toys/lsb/passwd.c:58:10: note: forward declaration of 'struct spwd'
  struct spwd *sp;
         ^
toys/lsb/passwd.c:93:14: error: implicit declaration of function 'crypt' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
      pass = crypt(toybuf+2048, pw->pw_passwd);
             ^
toys/lsb/passwd.c:93:12: warning: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion]
      pass = crypt(toybuf+2048, pw->pw_passwd);
           ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
toys/lsb/passwd.c:103:17: error: implicit declaration of function 'crypt' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    encrypted = crypt(toybuf, salt);
                ^
toys/lsb/passwd.c:103:15: warning: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion]
    encrypted = crypt(toybuf, salt);
              ^ ~~~~~~~~~~~~~~~~~~~
3 warnings and 4 errors generated.
.make: *** [Makefile:17: toybox] Error 1

Not make defconfig, make android_defconfig. Some commands don't build under the NDK.
The biggest chunk of them is the shadow password stuff, which I have a patch locally to rewrite (fixes ~5 commands I think) but I've bumped that until next release...

WAI and -- unlike macOS -- not obvious that make defconfig could ever auto-detect cross-compilation for Android...


WIP: Fixes the generated model of Filters.

Fixes the filters query string paramter that was being incorrectly
generated based on the go client type as it is an un-exported type and
internally Docker Client-Types modify it before serialization.
Signed-off-by: Justin Terry<EMAIL_ADDRESS>

@swernli - Give this a shot.

Replaced by #81


Facing issue during "make docker-build" for v0.26.0

i did following steps
git clone https://github.com/fluxcd/image-automation-controller -b v0.26.0
export DOCKER_CLI_EXPERIMENTAL=enabled
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
docker buildx create --use
make docker-build
I am getting following error

=> [linux/amd64->arm/v7 build 8/9] RUN   export PKG_CONFIG_PATH="/usr/local/$(xx-info triple)/lib/pkgconfig" &&   export CGO_LDFLAGS="$(pkg-config --static --libs --cflags libgit2) -static -fuse-
=> => # Package libgit2 was not found in the pkg-config search path.
=> => # Perhaps you should add the directory containing `libgit2.pc'
=> => # to the PKG_CONFIG_PATH environment variable
=> => # Package 'libgit2', required by 'virtual:world', not found

I tried to add libgit2 and libgit2-dev in Dockerfile
But I get below error

[linux/amd64->arm/v7 build 8/9] RUN export PKG_CONFIG_PATH="/usr/local/$(xx-info triple)/lib/pkgconfig" && export CGO_LDFLAGS="$(pkg-config --static --libs --cflags libgit2) -static -fuse-ld=lld" && xx-go build -ldflags "-s -w" -tags 'netgo,osusergo,static_build' -o /source-controller -trimpath main.go;:
#0 308.1 # github.com/libgit2/git2go/v33
#0 308.1 /go/pkg/mod/github.com/fluxcd/git2go/v33@v33.0.9-flux/Build_system_dynamic.go:12:3: error: "Invalid libgit2 version; this git2go supports libgit2 between v1.3.0 and v1.3.0"
#0 308.1 # error "Invalid libgit2 version; this git2go supports libgit2 between v1.3.0 and v1.3.0"
#0 308.1   ^
#0 308.1 1 error generated.

@samarth96 is there any specific reason why you are trying to build the v0.26.0 instead of main? We have recently deprecated the use of libgit2 in the controller, which removes all the complexity around building the project.
If you still need this, you can try recreating your buildx machine, as I suspect that may be the issue. This is what I used to build the docker images: https://github.com/fluxcd/golang-with-libgit2/blob/main/Makefile#L45-L55

I am using flux 0.35.0 and it requires v0.26.0 version of. image-automation-controller.
I used the buildx options you suggested above and I am still facing same issue
Here is complete output

[root@***** image-automation-controller]# docker buildx create --name local-builder1 --platform linux/amd64,linux/arm/v7,linux/arm64 --driver-opt network=host --driver-opt env.BUILDKIT_STEP_LOG_MAX_SIZE=1073741274 --driver-opt env.BUILDKIT_STEP_LOG_MAX_SPEED=5000000000000 --buildkitd-flags '--allow-insecure-entitlement security.insecure' --use
local-builder1

[root@***** image-automation-controller]# docker buildx build
--build-arg LIBGIT2_IMG=iad.ocir.io/siebeldev/dev/fluxcd/golang-with-libgit2-only
--build-arg LIBGIT2_TAG=v0.3.0
--platform=linux/amd64,linux/arm64,linux/arm/v7
-t fluxcd/image-automation-controller:latest
.
WARNING: No output specified with docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
[+] Building 11.0s (53/65)
=> [linux/amd64 xx 1/1] FROM iad.ocir.io/siebeldev/dev/fluxcd/tonistiigi/xx:1.1.2@sha256:a96ba6230d66c27afbd1bed8bd63b0774d021a590735d2fc525319895d3667bb                                             0.9s
=> => resolve iad.ocir.io/siebeldev/dev/fluxcd/tonistiigi/xx:1.1.2@sha256:a96ba6230d66c27afbd1bed8bd63b0774d021a590735d2fc525319895d3667bb                                                            0.8s
=> [linux/amd64 gostable 1/1] FROM iad.ocir.io/siebeldev/dev/fluxcd/golang:1.19-alpine@sha256:f33331e12ca70192c0dbab2d0a74a52e1dd344221507d88aaea605b0219a212f                                        0.9s
=> => resolve iad.ocir.io/siebeldev/dev/fluxcd/golang:1.19-alpine@sha256:f33331e12ca70192c0dbab2d0a74a52e1dd344221507d88aaea605b0219a212f                                                             0.8s
=> [linux/arm64 libgit2-libs 1/1] FROM iad.ocir.io/siebeldev/dev/fluxcd/golang-with-libgit2-only:v0.3.0@sha256:05c40119eb3f58b9d0bb43f8c6ba65b3ce24601cf9c4157f31a0793c1dca49d8                       0.9s
=> => resolve iad.ocir.io/siebeldev/dev/fluxcd/golang-with-libgit2-only:v0.3.0@sha256:05c40119eb3f58b9d0bb43f8c6ba65b3ce24601cf9c4157f31a0793c1dca49d8                                                0.8s
=> [linux/arm64 stage-7 1/5] FROM iad.ocir.io/siebeldev/dev/fluxcd/alpine:3.16@sha256:3d426b0bfc361d6e8303f51459f17782b219dece42a1c7fe463b6014b189c86d                                                0.9s
=> => resolve iad.ocir.io/siebeldev/dev/fluxcd/alpine:3.16@sha256:3d426b0bfc361d6e8303f51459f17782b219dece42a1c7fe463b6014b189c86d                                                                    0.8s
=> [linux/amd64 stage-7 1/5] FROM iad.ocir.io/siebeldev/dev/fluxcd/alpine:3.16@sha256:3d426b0bfc361d6e8303f51459f17782b219dece42a1c7fe463b6014b189c86d                                                0.9s
=> => resolve iad.ocir.io/siebeldev/dev/fluxcd/alpine:3.16@sha256:3d426b0bfc361d6e8303f51459f17782b219dece42a1c7fe463b6014b189c86d                                                                    0.7s
=> [linux/amd64 libgit2-libs 1/1] FROM iad.ocir.io/siebeldev/dev/fluxcd/golang-with-libgit2-only:v0.3.0@sha256:05c40119eb3f58b9d0bb43f8c6ba65b3ce24601cf9c4157f31a0793c1dca49d8                       0.8s
=> => resolve iad.ocir.io/siebeldev/dev/fluxcd/golang-with-libgit2-only:v0.3.0@sha256:05c40119eb3f58b9d0bb43f8c6ba65b3ce24601cf9c4157f31a0793c1dca49d8                                                0.6s
=> CACHED [linux/arm/v7 stage-7 2/5] RUN apk --no-cache add ca-certificates   && update-ca-certificates                                                                                0.0s
=> CACHED [linux/arm/v7 stage-7 3/5] RUN  ! -e /etc/nsswitch.conf  && echo 'hosts: files dns' > /etc/nsswitch.conf                                                                                0.0s
=> CACHED [linux/arm64 stage-7 2/5] RUN apk --no-cache add ca-certificates   && update-ca-certificates                                                                                0.0s
=> CACHED [linux/arm64 stage-7 3/5] RUN  ! -e /etc/nsswitch.conf  && echo 'hosts: files dns' > /etc/nsswitch.conf                                                                                0.0s
=> CACHED [linux/amd64 build-base 1/2] RUN apk add clang lld pkgconfig                                                                                0.0s
=> CACHED [linux/amd64 build-base 2/2] COPY --from=xx / /                                                                                0.0s
=> CACHED [linux/amd64 build-go-mod 1/5] WORKDIR /workspace                                                                                0.0s
=> CACHED [linux/amd64 build-go-mod 2/5] COPY api/ api/                                                                                0.0s
=> CACHED [linux/amd64 build-go-mod 3/5] COPY go.mod go.mod                                                                                0.0s
=> CACHED [linux/amd64 build-go-mod 4/5] COPY go.sum go.sum                                                                                0.0s
=> CACHED [linux/amd64 build-go-mod 5/5] RUN export http_proxy=http://www-proxy-hqdc.us.oracle.com:80 && export https_proxy=http://www-proxy-hqdc.us.oracle.com:80 && go mod download                 0.0s
=> CACHED [linux/amd64 build 1/9] COPY --from=libgit2-libs /usr/local/ /usr/local/                                                                                0.0s
=> CACHED [linux/amd64 build 2/9] RUN xx-apk add musl-dev gcc clang lld                                                                                0.0s
=> CACHED [linux/amd64 build 3/9] WORKDIR /workspace                                                                                0.0s
=> CACHED [linux/amd64 build 4/9] COPY main.go main.go                                                                                0.0s
=> CACHED [linux/amd64 build 5/9] COPY controllers/ controllers/                                                                                0.0s
=> CACHED [linux/amd64 build 6/9] COPY pkg/ pkg/                                                                                0.0s
=> CACHED [linux/amd64 build 7/9] COPY internal/ internal/                                                                                0.0s
=> [linux/amd64 build 8/9] RUN export LIBRARY_PATH="/usr/local/$(xx-info triple)" &&   export PKG_CONFIG_PATH="/usr/local/$(xx-info triple)/lib/pkgconfig" &&   export CGO_LDFLAGS="$(pkg-config --s  9.0s
=> CACHED [linux/amd64->arm/v7 build 1/9] COPY --from=libgit2-libs /usr/local/ /usr/local/                                                                                0.0s
=> CACHED [linux/amd64->arm/v7 build 2/9] RUN xx-apk add musl-dev gcc clang lld                                                                                0.0s
=> CACHED [linux/amd64->arm/v7 build 3/9] WORKDIR /workspace                                                                                0.0s
=> CACHED [linux/amd64->arm/v7 build 4/9] COPY main.go main.go                                                                                0.0s
=> CACHED [linux/amd64->arm/v7 build 5/9] COPY controllers/ controllers/                                                                                0.0s
=> CACHED [linux/amd64->arm/v7 build 6/9] COPY pkg/ pkg/                                                                                0.0s
=> CACHED [linux/amd64->arm/v7 build 7/9] COPY internal/ internal/                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 1/9] COPY --from=libgit2-libs /usr/local/ /usr/local/                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 2/9] RUN xx-apk add musl-dev gcc clang lld                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 3/9] WORKDIR /workspace                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 4/9] COPY main.go main.go                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 5/9] COPY controllers/ controllers/                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 6/9] COPY pkg/ pkg/                                                                                0.0s
=> CACHED [linux/amd64->arm64 build 7/9] COPY internal/ internal/                                                                                0.0s
=> CACHED [linux/amd64 stage-7 2/5] RUN apk --no-cache add ca-certificates   && update-ca-certificates                                                                                0.0s
=> CACHED [linux/amd64 stage-7 3/5] RUN  ! -e /etc/nsswitch.conf  && echo 'hosts: files dns' > /etc/nsswitch.conf                                                                                0.0s
=> [linux/amd64->arm64 build 8/9] RUN export LIBRARY_PATH="/usr/local/$(xx-info triple)" &&   export PKG_CONFIG_PATH="/usr/local/$(xx-info triple)/lib/pkgconfig" &&   export CGO_LDFLAGS="$(pkg-con  9.0s
=> => # Package libgit2 was not found in the pkg-config search path.
=> => # Perhaps you should add the directory containing libgit2.pc'                                                                                => => # to the PKG_CONFIG_PATH environment variable                                                                                => => # Package 'libgit2', required by 'virtual:world', not found                                                                                => [linux/amd64->arm/v7 build 8/9] RUN export LIBRARY_PATH="/usr/local/$(xx-info triple)" &&   export PKG_CONFIG_PATH="/usr/local/$(xx-info triple)/lib/pkgconfig" &&   export CGO_LDFLAGS="$(pkg-co  9.0s  => => # Package libgit2 was not found in the pkg-config search path.                                                                                => => # Perhaps you should add the directory containing libgit2.pc'
=> => # to the PKG_CONFIG_PATH environment variable
=> => # Package 'libgit2', required by 'virtual:world', not found


[RTM] Typo fixed in nipype

nipy/nipype#1784 has been merged, so we can track nipype/master. Remove version constraint from info.py, to avoid overwriting pinned copy.
Precondition for poldracklab/fmriprep#347.

Not sure if this will work with the pypi distribution of fmriprep. That will look into the info.py package and fall back to the latest full release of nipype (0.12). In that environment, requiring nipype>=0.13.0-rc2 is necessary.

Until we're ready to release, this is for people working off of master. If there's a better way to do it (e.g. a branch in poldracklab/niworkflows that's not master, that's fine with me.
Or am I missing something? Dealing with pins and versions is new to me.

Basically, we have two ways to declare dependencies in python packages (and therefore, you can pin packages to specific versions):
1 - Via pip and requirements.txt
2 - Via setuptools and the setup.py (in our case delegated to info.py).
When you run pip install fmriprep[install-opts] you are using option 2. It will fetch the package and run python setup.py install on it, and therefore take as requirement whatever it is declared as dependency in setup.py (our info.py). In theory, you could point here to git repos to install any branch of them using the link_dependencies option. In practice, this does not work very well. It could well be due to the shady way setuptools manages the link_dependencies or that nipype versioning is not 100% compatible with setuptools, I don't know :(. But the fact is we never got it to work well.
For development environments, then 1) is more appropriate. You need to run pip install -r requirements.txt (here's when pinning happens, and it is quite effective - whatever you have in the requirements file is installed). Then you can do pip install -e .[install-opts] to install the package in developer mode. If you don't run the pip install -r it will fall back to option 2).
I wish I could provide clearer descriptions, but this field is also very blurry to me.

This is just a temporary measure to help working with the bleeding edge versions of nipype. Before releasing we should revert back to specifying minimal version of nipype in info.py. Let's not worry about pypi until then.

Alright then!


Typo: Style Guide does not follow style guide: "Open API Initiative" vs "OpenAPI Initiative"

On: https://github.com/OAI/OpenAPI-Style-Guide
Under: The Initiative Name and Usage
The term "Open API Initiative" is used, though in the same sentence the rules state that there should be only 1 space (i.e. presumably it should be "OpenAPI Initiative" to be in line with the format used for "OpenAPI Specification").

Actually, it's supposed to contain TWO spaces as corrected by #1. It is indeed Open API Initiative and OpenAPI Specification.


AO-19984: Add go1.16 to the test matrix

Add go1.16 to the test matrix.
See also https://swicloud.atlassian.net/browse/AO-19984

Codecov Report

Merging #176 (3d266ee) into master (6b9163f) will decrease coverage by 0.18%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   82.17%   81.98%   -0.19%
==========================================
  Files          40       40
  Lines        4292     4292
==========================================
- Hits         3527     3519       -8
- Misses        631      638       +7
- Partials      134      135       +1

Impacted Files
Coverage Δ

v1/ao/internal/host/observer.go
80.45% <0.00%> (-4.52%)
:arrow_down:

v1/ao/internal/reporter/reporter_grpc.go
76.52% <0.00%> (-0.34%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6b9163f...3d266ee. Read the comment docs.


@auth must allow authentication against custom claims in Cognito User Pool

Is your feature request related to a problem? Please describe.
I need to authorize a custom claim (example tenantID for multi-tenant app) in addition to group ownership in @auth directive.
Describe the solution you'd like
Please allow custom claim to be validated against a field in the dynamoDB table for @auth directive. This is very similar to @group ownership directive.
Describe alternatives you've considered
If I have a lot of tenants each with a number of groups - read-only, admin, root, power-users etc... then 1 alternative was to treat tenantID+group as a different group. But this would be too many combinations of groups and will quickly hit the hard limit of groups for the cognito User pool. The other option is to write a pipeline resolver just for this purpose. But this is also not ideal and need a declarative method of authorization against any custom claims as possible. Hence the suggested solution.
Additional context
Reinvent 2018 talks of Multi-tenant SaaS to build good isolation down to data layer

Owner permissions currently allow specifying an arbitrary claim by using the 'identityField' parameter.
If you want to process a claim that holds an array of strings, a current option is to add more items to the 'cognito:groups' claim using a Cognito Pre-Token Lambda. The documentation shows group modifications here. I do not use this myself, but I don't think its subject to limits of Cognito-managed groups.
Lastly, I have also requested this feature as well and currently have this implemented in a fork. A patch file you can use is attached to #1899.

Thanks @RossWilliams. Is there documentation for the identityField parameter?
At a quick glance, the Pre-Token feels like a band-aid to the problem and can only go so far.
I am a bit unclear how to use the patch file and fork that you have pointed out. Any reason why it has not been incorporated in the main branch. Are there other design considerations

It’s not well explained in the documentation, but if you create a test schema and inspect the generated templates it should be clearer.
The patch file is a git patch file, just with a different extension. Adding it into the repo needs someone to do the work for tests and documentation.


PublicIPAddress support

Hello!
I want to add VM instances support in crossplane/provider-azure.
This is first part of big patch with Public IP addresses support
Description of your changes
Add support of Public IP Address.
Fixes https://github.com/crossplane/provider-azure/issues/208
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable test to ensure this PR is ready for review.

How has this code been tested
Same like in other resources like Subnet and VisrtualNetwork. And also manually tested

Hi @ulucinar thank you! I've commit fixes

Hi @vaspahomov,
Thank you for working on this PR. I'm planning to merge this and maybe address some remaining comments in a follow-up PR? What do you think?

Thank you very much @vaspahomov, merging this PR.

@vaspahomov, I've just opened a follow-up PR.


Add sql dump data to catalogue db

MySQL container is empty, it should be populated by dump.sql file (currently in catalogue repo only).  Once this is in place we can release the catalogue service so it will properly use the mysql db.

Done.