Temperature wheel is not working properly

Describe the bug
The temperature wheel sticks to a certian spot when sliding to colder values.
Related devices
Only tested with IKEA light bulbs.
To Reproduce

Change temperature value in homekit and have a look at homebridge log at the same time.
Value 250 is almost 2/3 of the temperature wheel.
when releasing the temperature wheel the dot will snap to a another point on the wheel

Expected behavior
The dot should not snap to a point when release
Versions used
Please provide the version of the following pieces of software:

plugin v1.1.1
homebridge v1.3.1-latest and 1.3.2-beta.0
Zigbee2MQTT 1.18.1
Homebridge Config UI X v4.39.1

I think this is because the MQTT messages with the updated state coming from Zigbee2MQTT arrive a bit later.
Is it possible for you to put the Homebridge (debug) logs and the MQTT messages (or logs from Zigbee2MQTT) side by side?
I think that way my "hypothesis" can be checked.

It seems to be an issue with Zigbee2MQTT.
I will report the issue there

It seems to be an issue with Zigbee2MQTT.

@T-IOOO I do wonder how you came to that conclusion. Can you share your findings (for future reference)?

I don't think it's a z2m issue, been doing some digging over in https://github.com/Koenkk/zigbee2mqtt/issues/6540.
Newer version of z2m respect the min/max values reported by the device. e.g. for tradfri this is 250-454 for color_temp.
It's in the expose data too.
Setting sometime out of range get update to be in range, the device ignores it (at best) or throws INVALID_VALUE otherwise.
I think we just need to pass this info to homekit. (I did some tests with node-red).
Default: 140-500

So when setting to 140 on tradfri, it will set 250 instead. Once the bulb/z2m reports the change it will snap to 250. (As expected).
When you pass the min/max to homekit it looks like:

Now everything on the selector is withing the 250-454 so there is no issue.
I think the code should end up here:
https://github.com/itavero/homebridge-z2m/blob/fe849f6493baa84ff116bbce212cd905fb32b8f9/src/converters/light.ts#L163-L172
Maybe something like
  private tryCreateColorTemperature(features: ExposesEntryWithProperty[], service: Service) {
    this.colorTempExpose = features.find(e => e.name === 'color_temp' && exposesHasNumericRangeProperty(e) && exposesCanBeSet(e)
      && exposesIsPublished(e)) as ExposesEntryWithNumericRangeProperty;
    if (this.colorTempExpose !== undefined) {
      const characteristic = getOrAddCharacteristic(service, hap.Characteristic.ColorTemperature);
      characteristic.on('set', this.handleSetColorTemperature.bind(this));
      characteristic.etProps({
        minValue: this.colorTempExpose.value_min,
        maxValue: this.colorTempExpose.value_max,
        minStep: 1,
      });
      this.monitors.push(new PassthroughCharacteristicMonitor(this.colorTempExpose.property, service,
        hap.Characteristic.ColorTemperature));
    }
  }

It seems to be an issue with Zigbee2MQTT.

@T-IOOO I do wonder how you came to that conclusion. Can you share your findings (for future reference)?

Sorry, it was just a thought. Still investigating. I have no idea whats causing this

@sjorge Thanks for figuring it out. This does sound like a logical explanation. I'll adjust the code so it passes along the min and max values to HomeKit.

Just released v1.1.2 with a change similar to what @sjorge (it was almost fully correct, thanks again!).
I hope this improves the experience for you, @T-IOOO.
Closing this issue for now. If the problem persists, feel free to reopen it.

Just updated to v1.1.2 and it seems to be working. I will test it out more tomorrow. One thing I noticed though is that the wheel is looking just as @sjorge mentioned. That warm hue in the cool area

I don't know how it works but it looks really ugly like this. I tested v1.1.2 but still same output as before. The wheel has a very small span that updates when you change the temperature color. It feels glitchy I think.
Try pressing one of the dots to change color and place the marker in the cool area of the wheel. Then close and go back again and the marker will change spot.

I am considering going back and use the plugin "Homebridge Mqtt Ikea Accesories" again.
It's not a practical plugin and needs more configuring but it worked better.

devices.zip
here's my information from zigbee2mqtt/bridge/devices

All your lights appear to indicate a range of 250 - 454 mired. Since they are all IKEA lights, I think it would be interesting to see how they expose it to HomeKit themselves.
It might just be a bug in the Home app to show the control this way.
Unfortunately I don't own such an IKEA bulb myself as far as I'm aware (don't see any in my list of devices at least and all my lights that support a color temperature indicate a much wider range from 150 to 500 mired).
If someone has these lights and an official IKEA TRADFRI gateway, I think a good next step would be to use the official HomeKit integration and see how it is exposed by their gateway. Maybe we are missing something obvious here or maybe it has the same "weird" gradient.
PS: Reopening this issue, as it's not 100% solved yet (and I'm not 100% sure yet where this can/should be solved).
PPS: I do have the TRADFRI gateway.

Unfortunately I don't own such an IKEA bulb myself as far as I'm aware (don't see any in my list of devices at least and all my lights that support a color temperature indicate a much wider range from 150 to 500 mired).

That's not necessarily correct either, z2m has only recently been reading colorTempPhysicalMin and colorTempPhysicalMax. And this is not automatically added to expose, as expose has no access to the data.
https://github.com/Koenkk/zigbee-herdsman-converters/blob/a242c73a73f9b66715f1acb4529187dd2b3dbe48/devices.js#L78-L88
The expose data got added manually were it was known, so Trådfri, some Innr, some Tint. But in generally RGB bulbs have a wide range of usually  close to 150 - 500, which is also the old (and default) expose range.
https://github.com/Koenkk/zigbee-herdsman-converters/blob/a242c73a73f9b66715f1acb4529187dd2b3dbe48/lib/exposes.js#L230-L232
z2m is also no longer sending out of range values if it has read colorTempPhysicalMin/Max. As mentioned earlier, as bulbs either ignore it or throw INVALID_VALUE.  Sending 150 to a non WS only Trådfri bulb, it will ignore it as it is out of range, z2m will send 250 instead and log a debug message that the value is out of range of the bulb.
The reading colorTempPhysicalMin/Max is done automatically when the bulb is reconfigured. But for a lot of older bulbs we've never seen database.db entries so we don't know the value.
An alternative would be to not limit the homekit range and ignore the state updates from z2m. That would also avoid the jumping around of the color picker
Before homekit min/max: pick 150 -> z2m sends 250 and logs warning -> bulb reports 250 is the new color temp -> homekit gets updated to 250 (selection jumps around)
With homekit min/max: pick 250 (can't go lower) -> z2m sends 250 -> bulb reports 250 -> homekit doesn't need update as selection is already 250.
So not passing min/max and ignoring the state update from z2m will also fix the jumping around, but that seems like the sub optimal fix as you then give users the impression they can select a color temperature that is not possible by the bulb.

I would prefer not to ignore any updates from Zigbee2MQTT, as that might give users the wrong impression and state will definitely get out of sync.
Just wondering: if @T-IOOO still sees the jumping, can that mean that the range reported in the exposes information of Zigbee2MQTT for the IKEA bulbs is still incorrect, @sjorge?
If I understand correctly, this would be visible in the Zigbee2MQTT log, right?

Easier way to verify is to reconfigure the bulb and grab the database entry.
I reconfigured all the ones I had and grabbed the entries:
TRADFRI bulb GU10 WS 400lm
{"id":37,"type":"Router","ieeeAddr":"0x680ae2fffe22fbb7","nwkAddr":39978,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"TRADFRI bulb GU10 WS 400lm","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":268,"inClusterList":[0,3,4,5,6,8,768,4096,64636],"outClusterList":[5,25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"TRADFRI bulb GU10 WS 400lm","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":2,"appVersion":32,"stackVersion":98,"hwVersion":1,"dateCode":"20200312","swBuildId":"2.0.029"}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":254,"onOffTransitionTime":5,"startUpCurrentLevel":255}},"lightingColorCtrl":{"attributes":{"currentX":30137,"currentY":26909,"colorTemperature":370,"colorCapabilities":16,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454,"startUpColorTemperature":65535,"options":0,"colorMode":1}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1}],"configuredReportings":[{"cluster":6,"attrId":0,"minRepIntval":0,"maxRepIntval":300,"repChange":0},{"cluster":8,"attrId":0,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":7,"minRepIntval":3,"maxRepIntval":300,"repChange":1}],"meta":{"scenes":{"42_10113":{"state":{"color":{"x":0.5018,"y":0.4153},"state":"OFF"}},"171_10100":{"state":{"color_temp":250}},"172_10100":{"state":{"color_temp":370}},"173_10100":{"state":{"color_temp":454}}}}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[33],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":32,"stackVersion":98,"hwVersion":1,"dateCode":"20200312","swBuildId":"2.0.029","zclVersion":2,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615137226238}

            "colorTempPhysicalMin": 250,
            "colorTempPhysicalMax": 454,

FLOALT panel WS 30x30
{"id":13,"type":"Router","ieeeAddr":"0x14b457fffe2fee7a","nwkAddr":396,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"FLOALT panel WS 30x30","epList":[1],"endpoints":{"1":{"profId":49246,"epId":1,"devId":544,"inClusterList":[0,3,4,5,6,8,768,2821,4096],"outClusterList":[5,25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"FLOALT panel WS 30x30","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":1,"appVersion":18,"stackVersion":87,"hwVersion":1,"dateCode":"20201102","swBuildId":"2.3.068"}},"genOnOff":{"attributes":{"onOff":0,"startUpOnOff":1}},"genLevelCtrl":{"attributes":{"currentLevel":64,"onOffTransitionTime":1,"startUpCurrentLevel":0}},"lightingColorCtrl":{"attributes":{"colorTemperature":370,"colorCapabilities":16,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454,"currentX":30137,"currentY":26909,"startUpColorTemperature":65535,"options":1}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1}],"configuredReportings":[{"cluster":6,"attrId":0,"minRepIntval":0,"maxRepIntval":300,"repChange":0},{"cluster":8,"attrId":0,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":7,"minRepIntval":3,"maxRepIntval":300,"repChange":1}],"meta":{"scenes":{"42_10110":{"state":{"brightness":64,"state":"ON"}},"171_10100":{"state":{"color_temp":250}},"172_10100":{"state":{"color_temp":370}},"173_10100":{"state":{"color_temp":454}}}}}},"appVersion":18,"stackVersion":87,"hwVersion":1,"dateCode":"20201102","swBuildId":"2.3.068","zclVersion":1,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615137200287}

            "colorTempPhysicalMin": 250,
            "colorTempPhysicalMax": 454,

FLOALT panel WS 30x90
{"id":15,"type":"Router","ieeeAddr":"0xec1bbdfffe9f5f8f","nwkAddr":46981,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"FLOALT panel WS 30x90","epList":[1],"endpoints":{"1":{"profId":49246,"epId":1,"devId":544,"inClusterList":[0,3,4,5,6,8,768,2821,4096],"outClusterList":[5,25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"FLOALT panel WS 30x90","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":1,"appVersion":18,"stackVersion":87,"hwVersion":1,"dateCode":"20201102","swBuildId":"2.3.068"}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":64}},"lightingColorCtrl":{"attributes":{"colorTemperature":370,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454,"colorCapabilities":16,"currentX":30137,"currentY":26909,"startUpColorTemperature":65535,"options":1}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1}],"configuredReportings":[{"cluster":6,"attrId":0,"minRepIntval":0,"maxRepIntval":300,"repChange":0},{"cluster":8,"attrId":0,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":7,"minRepIntval":3,"maxRepIntval":300,"repChange":1}],"meta":{"scenes":{"42_10110":{"state":{"brightness":64,"state":"ON"}},"171_10100":{"state":{"color_temp":250}},"172_10100":{"state":{"color_temp":370}},"173_10100":{"state":{"color_temp":454}}}}}},"appVersion":18,"stackVersion":87,"hwVersion":1,"dateCode":"20201102","swBuildId":"2.3.068","zclVersion":1,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615137199738}

            "colorTempPhysicalMin": 250,
            "colorTempPhysicalMax": 454,

GUNNARP panel 40*40
{"id":12,"type":"Router","ieeeAddr":"0x680ae2fffead5c39","nwkAddr":39576,"manufId":4476,"manufName":"IKEA of Sweden","powerSource":"Mains (single phase)","modelId":"GUNNARP panel 40*40","epList":[1,242,254],"endpoints":{"1":{"profId":260,"epId":1,"devId":268,"inClusterList":[0,3,4,5,6,8,768,4096],"outClusterList":[5,25,32,4096],"clusters":{"genBasic":{"attributes":{"modelId":"GUNNARP panel 40*40","manufacturerName":"IKEA of Sweden","powerSource":1,"zclVersion":3,"appVersion":33,"stackVersion":99,"hwVersion":1,"dateCode":"20190114","swBuildId":"2.3.050"}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":254,"onOffTransitionTime":5,"startUpCurrentLevel":255}},"lightingColorCtrl":{"attributes":{"currentX":30137,"currentY":26909,"colorTemperature":454,"colorCapabilities":16,"colorTempPhysicalMin":250,"colorTempPhysicalMax":454,"startUpColorTemperature":65535,"options":1}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1}],"configuredReportings":[{"cluster":6,"attrId":0,"minRepIntval":0,"maxRepIntval":300,"repChange":0},{"cluster":8,"attrId":0,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":7,"minRepIntval":3,"maxRepIntval":300,"repChange":1}],"meta":{"scenes":{"42_10108":{"state":{"brightness":3,"state":"ON"}},"171_10100":{"state":{"color_temp":250}},"172_10100":{"state":{"color_temp":370}},"173_10100":{"state":{"color_temp":454}}}}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[33],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}},"254":{"epId":254,"inClusterList":[],"outClusterList":[],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":33,"stackVersion":99,"hwVersion":1,"dateCode":"20190114","swBuildId":"2.3.050","zclVersion":3,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615137224640}

            "colorTempPhysicalMin": 250,
            "colorTempPhysicalMax": 454,

For comparisons a Tint bulbs
Tint LED bulb GU10/E14/E27 350/470/806 lumen, dimmable, color, opal white
{"id":81,"type":"Router","ieeeAddr":"0x000d6ffffe63cca0","nwkAddr":7368,"manufId":4635,"manufName":"MLI","powerSource":"Mains (single phase)","modelId":"ZBT-ExtendedColor","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":269,"inClusterList":[0,3,4,5,6,8,768,2821,4096,65244],"outClusterList":[10,25],"clusters":{"genBasic":{"attributes":{"modelId":"ZBT-ExtendedColor","manufacturerName":"MLI","powerSource":1,"zclVersion":2,"appVersion":1,"stackVersion":1,"hwVersion":1,"dateCode":"20181025-69","swBuildId":"2.2"}},"lightingColorCtrl":{"attributes":{"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":555,"currentX":30137,"currentY":26909,"colorTemperature":26909,"currentHue":0,"currentSaturation":254,"colorMode":0,"startUpColorTemperature":65535,"options":1}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":254}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":8,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1},{"cluster":768,"type":"endpoint","deviceIeeeAddress":"0x00124b00228120b5","endpointID":1}],"configuredReportings":[{"cluster":6,"attrId":0,"minRepIntval":0,"maxRepIntval":300,"repChange":0},{"cluster":8,"attrId":0,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":7,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":0,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":1,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":3,"minRepIntval":3,"maxRepIntval":300,"repChange":1},{"cluster":768,"attrId":4,"minRepIntval":3,"maxRepIntval":300,"repChange":1}],"meta":{"scenes":{"42_10106":{"state":{"brightness":25,"state":"ON"}},"171_10100":{"state":{"color_temp":250}},"172_10100":{"state":{"color_temp":370}},"173_10100":{"state":{"color_temp":454}}}}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":1,"stackVersion":1,"hwVersion":1,"dateCode":"20181025-69","swBuildId":"2.2","zclVersion":2,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615137206149}

            "colorTempPhysicalMin": 153,
            "colorTempPhysicalMax": 555,

The extreme range here makes sense, as it's a RGB bulb... anything anything outside of 200-400 is range is very dimm and ugly. The bulb does take it. These also have expose data that raises the max to 555 instead of 500.

The jump behaves like this: I choose one of the six colors in the palette, chose to edit color. When the temp wheel comes up and I pick the coolest temperature and then tap done and then go back again, the marker will be somewhere else. It is as if only 20% of the wheel is responding to changes when picking temp color. So the coolest color is actually at the blue/red area (see image in my earlier post)

@sjorge All the unique devices from my database that contian the colorTempPhysicalMin:
{"id":13,"type":"Router","ieeeAddr":"0x0017880106117ff9","nwkAddr":46616,"manufId":4107,"manufName":"Philips","powerSource":"Mains (single phase)","modelId":"LCT024","epList":[11,242],"endpoints":{"11":{"profId":49246,"epId":11,"devId":528,"inClusterList":[0,3,4,5,6,8,4096,768,64513],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"LCT024","manufacturerName":"Philips","powerSource":1,"zclVersion":1,"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20191218","swBuildId":"1.50.2_r30933"}},"genOnOff":{"attributes":{"onOff":1}},"genLevelCtrl":{"attributes":{"currentLevel":254}},"lightingColorCtrl":{"attributes":{"colorTemperature":274,"currentX":26077,"currentY":25450,"currentHue":37,"currentSaturation":38,"colorCapabilities":31,"colorTempPhysicalMin":153,"colorTempPhysicalMax":500}}},"binds":[{"cluster":6,"type":"endpoint","deviceIeeeAddress":"0x00124b001caa69fb","endpointID":1}],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[33],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":2,"stackVersion":1,"hwVersion":1,"dateCode":"20191218","swBuildId":"1.50.2_r30933","zclVersion":1,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615139283066}
{"id":29,"type":"Router","ieeeAddr":"0x00124b001ea819d9","nwkAddr":49003,"manufId":0,"manufName":"GLEDOPTO","powerSource":"Mains (single phase)","modelId":"GL-FL-004TZS","epList":[11,13],"endpoints":{"11":{"profId":49246,"epId":11,"devId":528,"inClusterList":[0,3,4,5,6,8,768],"outClusterList":[],"clusters":{"genBasic":{"attributes":{"modelId":"GL-FL-004TZS","manufacturerName":"GLEDOPTO","powerSource":1,"zclVersion":1,"appVersion":1,"stackVersion":2,"hwVersion":1,"dateCode":"20131206","swBuildId":"1.0.4"}},"genOnOff":{"attributes":{"onOff":0}},"genLevelCtrl":{"attributes":{"currentLevel":1}},"lightingColorCtrl":{"attributes":{"colorTemperature":495,"currentX":34070,"currentY":11432,"colorCapabilities":31,"colorTempPhysicalMin":155,"colorTempPhysicalMax":495}}},"binds":[],"configuredReportings":[],"meta":{}},"13":{"profId":49246,"epId":13,"devId":528,"inClusterList":[4096],"outClusterList":[4096],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":1,"stackVersion":2,"hwVersion":1,"dateCode":"20131206","swBuildId":"1.0.4","zclVersion":1,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1615139282438}
{"id":48,"type":"Router","ieeeAddr":"0x60a423fffe04207d","nwkAddr":44129,"manufId":4687,"manufName":"GLEDOPTO","powerSource":"Unknown","modelId":"GL-FL-006P","epList":[11,242],"endpoints":{"11":{"profId":260,"epId":11,"devId":269,"inClusterList":[0,3,4,5,6,8,768,4096],"outClusterList":[25],"clusters":{"genBasic":{"attributes":{"modelId":"GL-FL-006P","manufacturerName":"GLEDOPTO","powerSource":0,"zclVersion":3,"appVersion":0,"stackVersion":0,"hwVersion":0,"dateCode":"20201201","swBuildId":"V_1_2"}},"lightingColorCtrl":{"attributes":{"colorCapabilities":31,"colorTempPhysicalMin":158,"colorTempPhysicalMax":495,"colorTemperature":250,"currentX":17623,"currentY":43739}},"genLevelCtrl":{"attributes":{"currentLevel":254}},"genOnOff":{"attributes":{"onOff":1}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":0,"stackVersion":0,"hwVersion":0,"dateCode":"20201201","swBuildId":"V_1_2","zclVersion":3,"interviewCompleted":true,"meta":{"configured":2},"lastSeen":1614450095002}

Philips LCT001: 153 - 500 mired
Philips LCT024: 153 - 500 mired
Gledopto GL-FL-004TZS: 155 - 495 mired
Gledopto GL-FL-006P: 158 - 495 mired

As per your image in the z2m thread:

Is more or less accurate, anything the blue box is <250 which is out of range of the Trådfri bulb. e.g. bottom of the wheel is  ~ 140 mireds. So once the bulb is update it will be at 250 mireds as it  can't go lower and report that. Homekit will then update to 250 mires which is in the red box in your image. Now left and right side of the wheel are the same... so not sure how homekit decides on which side of the screen to put the selector. But it seems to always be left side for me.
[root@amethyst ~]# tail -f $(svcs -L zigbee2mqtt) | grep 'office/light/main/panel1'
Zigbee2MQTT:debug 2021-03-07 18:29:43: Received Zigbee message from 'office/light/main/panel1', type 'attributeReport', cluster 'genLevelCtrl', data '{"currentLevel":64}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2021-03-07 18:29:43: MQTT publish: topic 'zigbee2mqtt/office/light/main/panel1', payload '{"brightness":64,"color":{"hue":0,"saturation":100,"x":0.5056,"y":0.4152},"color_options":{"execute_if_off":true},"color_temp":370,"color_temp_startup":65535,"linkquality":123,"power_on_behavior":"off","state":"OFF","update":{"state":"idle"}}'
Zigbee2MQTT:debug 2021-03-07 18:29:47: Received MQTT message on 'zigbee2mqtt/office/light/main/panel1/set/state' with data 'ON'
Zigbee2MQTT:debug 2021-03-07 18:29:47: Publishing 'set' 'state' to 'office/light/main/panel1'
Zigbee2MQTT:debug 2021-03-07 18:29:47: Received Zigbee message from 'office/light/main/panel1', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2021-03-07 18:29:47: MQTT publish: topic 'zigbee2mqtt/office/light/main/panel1', payload '{"brightness":64,"color":{"hue":0,"saturation":100,"x":0.5056,"y":0.4152},"color_options":{"execute_if_off":true},"color_temp":370,"color_temp_startup":65535,"linkquality":123,"power_on_behavior":"off","state":"ON","update":{"state":"idle"}}'
Zigbee2MQTT:info  2021-03-07 18:29:47: MQTT publish: topic 'zigbee2mqtt/office/light/main/panel1', payload '{"brightness":64,"color":{"hue":0,"saturation":100,"x":0.5056,"y":0.4152},"color_options":{"execute_if_off":true},"color_temp":370,"color_temp_startup":65535,"linkquality":123,"power_on_behavior":"off","state":"ON","update":{"state":"idle"}}'
Zigbee2MQTT:debug 2021-03-07 18:29:57: Received MQTT message on 'zigbee2mqtt/office/light/main/panel1/set/color_temp' with data '150'
Zigbee2MQTT:debug 2021-03-07 18:29:57: Requested color_temp 150 is lower than minimum supported 250, using minimum!
Zigbee2MQTT:debug 2021-03-07 18:29:57: Publishing 'set' 'color_temp' to 'office/light/main/panel1'
Zigbee2MQTT:debug 2021-03-07 18:29:57: Received Zigbee message from 'office/light/main/panel1', type 'attributeReport', cluster 'lightingColorCtrl', data '{"colorTemperature":250}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2021-03-07 18:29:57: MQTT publish: topic 'zigbee2mqtt/office/light/main/panel1', payload '{"brightness":64,"color":{"hue":0,"saturation":100,"x":0.5056,"y":0.4152},"color_options":{"execute_if_off":true},"color_temp":250,"color_temp_startup":65535,"linkquality":123,"power_on_behavior":"off","state":"ON","update":{"state":"idle"}}'
Zigbee2MQTT:info  2021-03-07 18:29:57: MQTT publish: topic 'zigbee2mqtt/office/light/main/panel1', payload '{"brightness":64,"color":{"hue":0,"saturation":100,"x":0.5056,"y":0.4152},"color_options":{"execute_if_off":true},"color_temp":250,"color_temp_startup":65535,"linkquality":123,"power_on_behavior":"off","state":"ON","update":{"state":"idle"}}'

The important bit is:
Zigbee2MQTT:debug 2021-03-07 18:29:57: Received MQTT message on 'zigbee2mqtt/office/light/main/panel1/set/color_temp' with data '150'
Zigbee2MQTT:debug 2021-03-07 18:29:57: Requested color_temp 150 is lower than minimum supported 250, using minimum!
Zigbee2MQTT:debug 2021-03-07 18:29:57: Publishing 'set' 'color_temp' to 'office/light/main/panel1'
Zigbee2MQTT:debug 2021-03-07 18:29:57: Received Zigbee message from 'office/light/main/panel1', type 'attributeReport', cluster 'lightingColorCtrl', data '{"colorTemperature":250}' from endpoint 1 with groupID 0

The bulb report 250 as expected so homekit will update from 150 -> 250

Im not an experienced programmer but is this any help to gather correct values for bulbs?
https://github.com/czhDavid/homebridge-mqttIkeaAccesories
I have been using this plugin before I migrated to z2m and everything worked as it should.

Checked their source code and they have a "hack" in there: the tell HomeKit that it supports a larger color temperature range and then "linearize" it to the smaller range.
Although this might work, in my opinion it's a hack and not very transparent.
I just remembered that I might still have an IKEA TRADFI lightbulb in one of moving boxes. If I can find it, I might be able to see how IKEA exposes their lights.

Interresting. I don’t know how it works except that the plugin itself works. I dont know how homekit translate the ”hack”. For example if homekit itself is able to correct values for acessories?

Hmmm that indeed and interesting hack where it maps the default HomeKit range to be within the trådfri range (which is the one z2m is hindering too)
although just telling HomeKit the valid range as we’re doing now seems more logical.
I’m curation to home the trådfri gateway is doing it, but also how others like hue do it.

Unfortunately I've been too busy with other stuff lately to take the time and setup my IKEA TRADFRI gateway and Philips Hue gateway again.
If someone else gets around to doing this, your help will be very much appreciated.
If not, I'll do it eventually, but I can't make any promises on when that will be.


Load balancer suggestion: Failover to IP hash when header is not present

<IP_ADDRESS>:2015 {
    proxy / example.com example.org {
        policy header X-MyHeader
    }
}

In this example, Caddy will throw a 502 Bad Gateway error when the client doesn't specify the X-MyHeader header. It would be nice to failover to IP hash instead of throwing that error. Thoughts?

Okay, it looks like you can reproduce it only when you have more than one host.

This is somehow is pretty easy to fix, but i'm not sure that fallback to iphash is best option. I will read about this.

I will write it here as well:
From the haproxy documentation:
  hdr(<name>) The HTTP header <name> will be looked up in each HTTP
              request. Just as with the equivalent ACL 'hdr()' function,
              the header name in parenthesis is not case sensitive. If the
              header is absent or if it does not contain any value, the
              roundrobin algorithm is applied instead.

They are doing round robin in case of missing header.

@mholt @tobya we can close this one


After Animation UI doesn't respond for 1-2 seconds

After that animation is finished in the two modes : Presentation & Dismissal , the UI doesn't respond :

you can not select anything ..for example for the demo application you can not neither select the menu button nor scrolling the tableView.

if you remove "elasticity" animation of "UIDynamicItemBehavior" (GuillotineTransitionAnimation  class line #124)
and you move "animationContext.completeTransition" from "dynamicAnimatorDidPause" to "collisionBehavior :  beganContactForItem:  withItem:, atPoint :"
this will be resolved but the elasticity animation will be removed.

sorry for long time no reply. you can add the itemBehaviour.resistance = 0.5 around line 123 in the GuillotineTransitionAnimation.swift file. This should fix the problem. Unfortunately I did not reproduce the bug. Let me know how did it work for you.

@maksTheAwesome - I just tried it, and i did not work. In line #124 the code already is there with "1" and not 0.5. I tried changing it, but it did not work.

The new version of GuillotineMenu (2.0.1) is available. Feel free to check it out!

The issue still exist , Please reopen the issue.

The new version of GuillotineMenu (4.0) is available. Feel free to check it out!


Using trackDependency is not clear

trackDependency() from java script today accepts the following set of parameters:
(id, method, absoluteUrl, pathName, totalTime, success, resultCode, properties?, measurements?)

The pathName passed as a paramter, becomes the commandName and finally is seen as data in UI.

There is no traditional way to send a custom dependency telemetry (or overwrite certain properties). The only way to do that is to use initializers.

Can we expose something like TrackDependency(data), where we override properties only if they are null, and based on the url of the envelope?

Issue with not being able to customize the properties: https://github.com/Microsoft/ApplicationInsights-JS/issues/390


Changing the subquery builder for the Oracle

Description
Because Oracle does not support using the AS keyword for table aliases.
This PR removes the AS keyword when building subqueries.
Checklist:

[x] Securely signed commits
[x] User guide updated

Subquery has not been released. Do we need it to be written in the changelog?
https://codeigniter4.github.io/CodeIgniter4/changelogs/v4.2.0.html#others

@paulbalandan An improvement to the BaseBuilder::buildSubquery() method, namely adding an alias, has not yet been released.
But I added a description of this improvement to the changelog. https://github.com/codeigniter4/CodeIgniter4/pull/6006
If this PR and the fix in the changelog are merged before the release, then it seems to me that it makes no sense to further clarify the changes from this PR.

Ohh. I thought this was documented already. Thanks for the clarification.


Removing UIWebView support

Removing UIWebView support from this library, since Apple is now warning developers of the usage of the UIWebView APIs when submitting apps to the App Store for review.

Removed UIWebView support from the code, and the tests

2. Kept the WebView macOS support, as I don't think that has been targetted by Apple yet.

3. Updated the README.md file to remove any UIWebView references.

4. Update the podspec (version number, and description)

We are under the impression that since ht eUIWebView warning is being shown to all apps being submitted to Apple, that it's just a matter of time before iOS apps will not be allowed to ship with this code.  This will help eliminate that possibility.  If a user needs UIWebView support, they can always use the 6.x version of the library.
Thanks for taking a look at this patch @marcuswestin!

@marcuswestin  Here is the wording from Apple on submissions referencing UIWebView:

ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs . See https://developer.apple.com/documentation/uikit/uiwebview for more information.

How do I get the continuous-integration/travis-ci check to run for this PR?  I'd love to move this forward.

@marcuswestin Please take a look at this PR.
Apple published a note on December 23, 2019 stating that apps shipping with UIWebView support will be rejected as of April 2020.
Here's the link to the article:
Updating Apps that Use Web Views
This PR should remove UIWebView from the codebase.  I did not remove it from the macOS target, but I can do that work if you'd like.
We have several apps that rely on this framework, and would love to support your Open Source efforts with this patch to keep things working moving forward.
Thanks for the consideration.

@marcuswestin  It would be nice to get this PR merged and released before the April 2020 deadline.  It's February now, and people will need time to migrate up to the latest version of the SDK.   This update will eliminate the chance that a consuming app will have of being rejected by Apple upon submission in April.
Let me know if you have any questions.

The owner of the repository is probably won't support it anymore =(

Actually your pull request doesn't remove fully UIWebView code

Actually your pull request doesn't remove fully UIWebView code

Only UIWebView code I see in my branch is in the Example app.  I can remove it from there as well.

@stury take a look at WebViewJavascriptBridge.m it has conditional branching to use UIWebView if it's iOS version macros lower than iOS version with WKWebView

@GRyabkin  Sorry, you are correct!  Updated, and removed the rest of the references I could find.  Let me know if you see anything else I need to clean up.  All Tests pass, and the sample app works without UIWebView.

@stury thanks for your effort :)
I am exactly in a situation you described. Our new app rejected due to the usage of UIWebView, which comes from this package actually. Did you happen to fork from this project for your update?
Otherwise, I am going to use this one: https://cocoapods.org/pods/WKWebViewJavascriptBridge

@akbayt I did fork from this repo:  https://github.com/stury/WebViewJavascriptBridge/tree/Remove-UIWebView-Support
You can use that fork, or try out the WKWebViewJavascriptBridge.  I hadn't seen that one before.  Looks like they have the right idea.  Cheers!

@stury thanks for the quick answer.
WKWebViewJavascriptBridge didn't work for me. It doesn't give option to set WebView delegate (setWebViewDelegate), which necessary for me to handle URL redirections.
I will try your fork. I will try adding it manually since the pod installation doesn't work:
pod 'WebViewJavascriptBridge', '~> 7.0'
or do you have a pod with a different name?

@akbayt I believe I've merged everything to master at this point in my fork, so you should be able to just use the following:
pod 'WebViewJavascriptBridge', :git => 'git@github.com:stury/WebViewJavascriptBridge.git', :branch => 'master'
Or you can replace the git@github with the HTTPS URL if you'd rather:
pod 'WebViewJavascriptBridge', :git => 'https://github.com/stury/WebViewJavascriptBridge.git', :branch => 'master'
Give that a shot, and it should work.

@stury worked just fine!
I tested essential functionalities, all works fine. And also, I tried to upload a new version to the app store connect; it didn't give the warning about unsupported UIWebView.
Thanks, this saved my time a lot :)

Thank @stury , you save my day

@stury -Thank a lot.
You saved lots of time. When it will be available on the cocoa pod.
Once again thank you


Optimize: add login judgment before push

Describe what this PR does / why we need it
Add login judgment before push, if not logged in, push is not allowed.
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

Codecov Report
Patch coverage: 39.58% and project coverage change: +0.11 :tada:

Comparison is base (ca522b1) 18.68% compared to head (644c021) 18.79%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2104      +/-   ##
==========================================
+ Coverage   18.68%   18.79%   +0.11%
==========================================
  Files          95       96       +1
  Lines        8874     8921      +47
==========================================
+ Hits         1658     1677      +19
- Misses       6995     7017      +22
- Partials      221      227       +6

Impacted Files
Coverage Δ

pkg/config/config.go
27.95% <0.00%> (ø)

pkg/clusterfile/decoder.go
48.20% <25.92%> (-3.59%)
:arrow_down:

cmd/sealer/cmd/utils/application.go
60.00% <60.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

/test build

@Stevent-fei , could we check the entire cmd directory?  not only image dir.

pls update those at the same time@Stevent-fei


Add options to make Event Processor settings configurable.

Time interval for running the load balancer
Load balancer strategy
Ownership expiration duration.

Done in PR https://github.com/Azure/azure-sdk-for-java/pull/12932


Improved useDynamicMutation API

Jumping the gun and posting this WIP PR that @sgrove wrote with me today.
This is dependent on a proposed change to graphql_ppx_re (https://github.com/baransu/graphql_ppx_re/pull/48) that would add a definition variable containing the query, parse function and a special composeVariables function that lets us do cool API things.
Wanted to get some early feedback on the first one (useDynamicMutation) that we converted, but I'm also working on similar changes to useQuery/useMutation etc which could be neat. It seems to work well so far but I'm very interested if people spot any potential issues.
In case anyone is interested, though it looks a little complicated, this shouldn't make it any harder for non-graphql_ppx_re users to use the library. They would have to write something like this:
useQuery((a => a, "query", fn => fn(Js.Json.null)));

// We could even expose a helper function like this:
let jsonVars = (v, f) => f(v);
useQuery((a => a, "query", jsonVars(Js.Json.null)));

// Or like this..
let makeDefinition = (~parse: Js.Json.t => args, ~query: string) =>
  (parse, query, (f, vars: Js.Json.t) => f(vars));
Hooks.useQuery(Hooks.makeDefinition(~parse=a=>a, ~query="query"), Js.Json.null);

I'm pretty excited about this one @Schmavery and @sgrove, this is a really nice API! Thanks for all the hard work! I'd be happy to merge this – would one of you mind updating the API docs while you're here. I'm also thinking it'd be worth it in the near future to write up a short guide on using reason-urql w/out graphql_ppx_re so we can capture some of the comments from @Schmavery here, but that doesn't feel important for this PR.

Also, just let me know when you think it's safe to remove the WIP tag and formally merge this – I noticed that your changes in graphql_ppx_re just got merged, but not sure when a new version will get cut and we can formally pick those up.

@parkerziegler v0.4.0 of graphql_ppx_re got published, so I updated the example to that so that it can build/pass CI.
It looks like it's working so we can merge if you like :)
When I get a chance I'll rebase and finish https://github.com/FormidableLabs/reason-urql/pull/133.
I fixed some docs in this PR but I want to add more details and info about writing code that doesn't use graphql_ppx_re in that PR if that's ok with you.

Awesome, thanks so much for updating the docs. And thanks as well @sgrove, really grateful to have your help on this project! Merging now and will read through the other PR tonight.

@all-contributors add @sgrove for code, example, ideas and @Schmavery for docs.

@all-contributors add @Schmavery for docs.


SSE block event post deneb

The SSE block event is used currently to measure block propagation times. This data is critical to inform decisions like blob count and overall network health. In consensus clients blocks go through a few phases:

Arrival on gossip, before gossip validation
Completed gossip validation
Block imported (complete gossip, consensus, execution, and DA) validation
Block set as head

I believe both 2. and 3. are equally important event that convey different information. The API spec is vague such that you could interpret as having to emit the event on either 2. or 3.
https://github.com/ethereum/beacon-APIs/blob/8b52d949965d2294d3f0191c6b15644535a933fe/apis/eventstream/index.yaml#L50-L51
After deneb, the gap between 2. and 3. will be widen since clients must wait for arrival of all blobs. This will prevent researchers from timing block arrival times correctly.
I propose to have two separate events properly defined:

block: The node has imported a valid block into its fork-choice, received from P2P or API
block_gossip: The node received a block from gossip that pass gossip validity conditions of the beacon_block topic

CC: @parithosh

What's the gap between 3) and 4), in general?  Can they be far enough apart that they warrant separate events?
I'd prefer to keep the block event as at item 2, as one of its prime uses is to track propagation of blocks through the network.
3 and 4 could be argued as both being part of the 'import to state' phase of the process, is there a requirement out there to know the timing of item 3?

What's the gap between 3) and 4), in general? Can they be far enough apart that they warrant separate events?

Not all blocks end up being head, so for the same block hash event 4 may never be emitted. Also a block could be made head latter when there's enough LMD weight, so the gap between 3 and 4 ranges from 0 to infinity.

I'd prefer to keep the block event as at item 2, as one of its prime uses is to track propagation of blocks through the network.

We would have to check with all consumers of this event, because emitting at 2 means you can potentially emit invalid blocks. Not sure if this can break explorers and other uses. As of today, at least Lighthouse and Lodestar emit the block event at step 3.

3 and 4 could be argued as both being part of the 'import to state' phase of the process, is there a requirement out there to know the timing of item 3?

Not a strong requirement in timing in general, but they convey different information: 2. is precise in timing but may emit invalid blocks. 3. is imprecise in timing but is guaranteed to emit valid blocks.

Not a strong requirement in timing in general, but they convey different information: 2. is precise in timing but may emit invalid blocks. 3. is imprecise in timing but is guaranteed to emit valid blocks.

From what I know (and use) then generally block is used purely to track the arrival of blocks to the node and head is used to track the more interesting case of a change to the chain.  Given that, 3) seems to be falling between two stools and from my point of view I'm not sure that I would ever need that information.

"time received" vs "my rest server published it and the sse reader saw it and some more random delays in between" is a significant source of flakeyness. I certainly believe that we should be drawing no conclusions whatsoever from timing information received over /event util this is resolved.

I wouldn't object to the events being extended with a timestamp field that provided a ms-level timestamp.  There is history of events having additional fields (execution_optimistic springs to mind) so I don't think that this would be particularly controversial.

I wouldn't object to the events being extended with a timestamp field that provided a ms-level timestamp. There is history of events having additional fields (execution_optimistic springs to mind) so I don't think that this would be particularly controversial.

This would be really nice if possible 👍

From a consumer side, it would make sense to update all the existing relevant topics, block, attestation, voluntary_exit, bls_to_execution_change and contribution_and_proof,  and add one or more of the additional fields;

received_timestamp - arrival on gossip/API, before gossip/API validation
validated_timestamp - gossip/API validation
imported_timestamp - item imported

Possibly beyond the scope of this issue, but would it make sense to also publish invalid/not imported items for data collection?

I'm not sure how multiple timestamps would work.  You would either be holding the event back from the event stream until all timestamps were available, or you would be sending multiple events for the same item with the different timestamps as each point was reached.
I'd prefer to see each event be clearly defined in terms of when it should be timestamped, but also be emitted as soon as possible afterwards.  Having multiple timestamps starts to look like tracing, and should likely be handled with something like OpenTelemetry within the individual consensus clients.

Yeah fair, multiple events would also be great. I guess that would also cover my question about publishing items received from gossip but were invalid.

its non trivial for us to get he timestamp that it arrived, im not sure how practical it would be.... and our 'arrival' time is when we look at it. i'm not sure it'd be ideal to have to instrument the event as it goes through the system, currently its immutable...

@rolfyone would the point that the item (thinking block, here) finished P2P validation and is passed on for processing a suitable point at which the event could be generated?
As for the object being immutable, I assume that means that new event stream objects would have to be created to contain the timestamp information as well (unless you're passing JSON directly to the event API).  Would adding this be significant overhead?
Regarding multiple timestamps as data is received and processed: I agree that instrumenting it in-object would be painful, which is why I though of using telemetry as that can emit data points to the external system.  But we're wandering out of scope for this issue; perhaps @Savid could open a new issue to discuss tracing specifically?

i've got a CLI for triggering a block event after validation, but its not on by default because the optimistic flag at that point is basically meaningless..

One option may be

block validated event (new) - after block passes its validation but hasn't been imported - this could just be block root.
block imported event (current block event) - once block import is complete.

I think the vagueness of the block event is why we currently have it 'out of order'. To figure out the optimistic flag, its emitted after import completes, which for us means fork choice has been run (and potentially a head event emitted).
If there was an explicit block_validated or valid_block or something, then that would satisfy the flow where you want to see block before you see head event, because it would always happen before the block event (regardless of implementation demissions this would be a fair assertion to make). It also means that it only needs the root.
It concerns me that these events are being measured, because theres nothing requiring that head events must happen after block events, and as you say, block events are not defined super well.  Parts of the block event itself (the optimistic flag) does kind of imply an implementation. I guess arguably measuring validation and head events if we went this way would be a fairly accurate picture, regardless of client.

I would vote to define the event strictly to be emitted after full validation (gossip, consensus, execution, and DA) plus append a precise timestamp of received time before full validation. Would be good to collect from clients what's the earliest timestamp the can capture (before gossip validation or after).

Wouldn't it be simpler to use the delay since start of slot instead of a timestamp?

Wouldn't it be simpler to use the delay since start of slot instead of a timestamp?

Not sure if simpler, sounds mostly equivalent. For the purpose of measuring latency it is more straightforward but sounds less generic. @rolfyone @parithosh

Is the key point block propagation, or is the key point processing time from client to client? what are we trying to measure?
eg. if we get
block: 0x.... imported: 1100ms

that tells us when a block got imported by the client, so we'd know when things 'have' the block in their structures etc, but it doesn't tell us the block arrived at 0ms, and took until 1100ms to get processed....
if we get
valid_block: 0x.... arrived: 0ms, validated: 400ms
block: 0x.... imported 1100ms

then we see that the block arrived fine, took ages to validate, and 600ms until it was processed...
or do we want something like
block_gossip: 0x..... proposer: ....., timestamp <TIMESTAMP IN MS>
block_valid: 0x...., timestamp: <some kind of stamp>
blob_gossip: ... identifier, timestamp: <timestamp>
blob_valid: .... identifiers, timestamp....
blob_import: .... identifiers, timestamp....
block_import: 0x...., slot: 0x...,  timestamp: <some kind of stamp or delta into slot>

all of the events have overheads, so if we don't need them i suggest we don't add them, but if there's a good reason then we can add support. I just think we want a good idea of the problem we're solving before we look for a solution...
The more we add, obviously the more it takes to implement - but if its actually needed then it might be worth it. my caution would be if theres a lot of listeners on these events it'll potentially have negative impacts on clients, especially if we add a ton of events that some clients need to emit synchronously or something...

I mentioned this before, but I really don't think that the events output is the right place to contain this information.  It would require some sort of continuous instrumentation from the P2P layer throughout the entire stack as the block was validated and imported, and the event could not be emitted until the processing was complete.  Not only would this be a potentially large burden on client implementations, but it would somewhat subvert the point of the events stream being notifiers for external processes and turn it into a pseudo-tracing system.
Capturing the timestamp at which an item is pushed to the events system is a single metric that shouldn't be hard to implement (I'm making some assumptions here, but I think they're reasonable).  I'd rather that we nailed down the trigger for the block event here, and worry about telemetry elsewhere.
(I'm still voting for 2 as per the list of suggestions by @dapplion, it makes most sense to me as to be the point at which we are interested in knowing that a block has been seen by the node).

(I'm still voting for 2 as per the list of suggestions by @dapplion, it makes most sense to me as to be the point at which we are interested in knowing that a block has been seen by the node).

so that valid_block kind of event would be fine, and could add a timestamp that this event was fired to that.. that'd be easy.
I agree that this isn't the best place, and instrumentation always slows things down which does concern me, i'm just trying to make sure we're actually doing something thats fit for purpose without being a huge overhead...

but if there's a good reason then we can add support. I just think we want a good idea of the problem we're solving before we look for a solution...

The most immediate usecase is researches measuring block propagation through networks to inform EIP-4844 params. That's the best tool they got before having to develop full libp2p clients, on man in the middle attacks. They perform analysis on a per implementation basis, so each client being slightly divergent is not a problem, but each client should attempt to provide as best data as possible.

Actually it would be good to just know what events different clients expose currently.
As I understand, Nimbus for example exposes the event after adding the block the the DAG, so it includes several processing steps after reception and GossipSub validation.

The most immediate usecase is researches measuring block propagation through networks to inform EIP-4844 params.

This isn't the main purpose of the events stream, though.  If we're trying to track this information then I think that this is better off coming from telemetry rather than events.

I agree completely, this isn't really a great way to measure propagation, especially if you want timely data.

This isn't the main purpose of the events stream, though. If we're trying to track this information then I think that this is better off coming from telemetry rather than events.

Tagging ethpandaops since they are the main users of events for timing data: @samcm @parithosh

Yeah we're probably the ones that would most benefit from timing data being added to the event stream. I agree that it's not the right place for us to derive this info - telemetry/tracing makes way more sense. But it's all that we have at the moment, and is the only option that works with all client implementations. Even though we can't compare data between clients, comparing between the same client is still useful.
If we want to discourage this use-case from the events stream that's fine, but I would suggest that we try and find another unified and standardized way for clients to produce telemetry. We've seen a growing demand for this data over the last 12 months, and I expect it will continue to grow as we work on protocol upgrades. If we leave this up to clients to implement independently it'll be a nightmare for consumers 🙏

If that's what we want, maybe a block_valid with a timestamp that validation completed would suffice, and would need to define the valid term, id probably suggest when it has passed gossip validation?
Then when gossip validation finishes you'd get an event that just has basically the block root and timestamp...

Going through the discussions above, it sounds like we are interested to track:

when a node see a new block / blob (gossip verified)
when a node imports a block (fully validated)

It would be useful to understand the consumers of these events -  I'd assume app layers / L2s would be interested in only seeing valid block that are imported (2)? and (1) is useful mainly for measuring propagation, i.e. potentially for devs, ops, research etc.
If we only do (2) above, is it less useful for tracking block/blob arrivals? are potentially invalid block useful? or are we just interested in the block arrival time in general?

This was the original intention of the block event.

The problem i guess with the block event being 'validated' is that optimistic flag, which we know for sure once its imported, but at validation time we can only report if the head block is optimistic.

Late recap from ACDC 124 https://github.com/ethereum/pm/issues/922

Option
Pros
Cons

Add seen_timestamp property to the existing event
- Allows you to emit the event with low priority, timing not important (Enrico)
- Requires changing an existing event without versioning

Add new event block_gossip
- You get timing data also for state transition invalid blocks (sean)  - allows consumers to track timing for p2p only

Does not seem we have a well defined versioning strategy for SSE events. The block event was modified in the past to add the execution_optimistic flag, so are we generally okay with adding properties on the same event?
Another point brought up in the call was adding a valid flag to the event to denote invalid blocks. IMO that's a breaking change to the current event so it's worse than adding a new property like execution_optimistic or seen_timestamp.
Adding a timestamp property seems to invite the addition of more timestamps at different stages of the block lifetime. One can make an argument that the post gossip validation is the most valuable, but still something to consider. Similarly, if we add the block / block_gossip pair, why not add attestation / attestation_gossip pair too? This can be refuted tho as all the other p2p related events are expected to be emitted after gossip validation.
Next steps
Looking at the pros / cons I would:

strictly define block event emitted for imported blocks onto fork-choice
add a new block_* event emitted for blocks that pass gossip validation


Add skewed profiles; Extend Ne reference data

the problem is with  tests/protocols/test_calibrationmodel.py::test_laser_zeroing which seems to be fixed in #192


🚀 - Detect the end of scroll on Select/Multiselect/ComboBox

Which @taiga-ui/* package(s) are relevant/releated to the feature request?
kit
Description
Hello.
Is it possible to detect when user is scrolling down the items in dropdown of Select/Multiselect/ComboBox (in tui-data-list or tui-data-list-wrapper) and subscribe to this event e.g. there are can be a lot of items to load from server and display them? So it seems logical to load data from server in parts and display them in parts too, so when user is scrolling down the load event is calling and new data appends to the end of the list?

You mean virtual scroll? See here for example: https://taiga-ui.dev/components/multi-select#virtual
It is based on the Angular CDK: https://material.angular.io/cdk/scrolling/overview

Yes, you have 2 options - add scrollbar to the dropdown template yourself so that built-in dropdown scrolling does not happen or reach out for the tui-scrollbar through DOM API with some directive you can make. This is more like a question than a feature request — those are better suited for https://github.com/Tinkoff/taiga-ui/discussions


Convert QName.java to ASCII encoding and remove special character

Related #201
Signed-off-by: Adam Brousseau<EMAIL_ADDRESS>

@Mesbah-Alam are you able to test and review this please?

I am not sure why this file was not in ASCII already! Thanks for removing the spaces. It looks good. Hope this solves the intermittent issue in the build.


fix(v2): doc path special char (space or other) should lead to a valid slug

Motivation
Fixes https://github.com/facebook/docusaurus/issues/3223
Test Plan
tests

Error: Unable to resolve valid document slug. Maybe your slug frontmatter is incorrect? Doc id=node原理与解析 / dirName=node / frontmatterSlug=undefined => bad result slug=/node/node原理与解析

Hi @banli17
Can you open another issue for that?
I don't know much about chars like 原理与解析, are theese valid pathname characters? What do you expect the slug to be according to this id/filename?
As an escape hatch  you can write your own slug with the slug frontmatter

Note @banli17 this PR is not yet released. Please tell me if the upcoming release does not fix your issue, but I think it will.
Probably releasing next week

There is a bug when I use character #


segment fault when computing loss

Hi, I create the env using conda and right torch/cuda version. But when I try to run any script, it always produces Segmentation fault.
I have tested my env on other tasks like minist conv classifications.
I am on Centos, and I have tried gcc 4.8, 7.3 and 8.2.
Any suggestions?

Hi,
Its strange. The code is developed under Ubuntu but I think it is the same for Centos. Can you post any debug info?

Hi, I also got segmentation fault error while I ran the code inside docker container. But no problem in host PC. The system is Ubuntu18.04.

Unpinning   - cudatoolkit=9.0 to - cudatoolkit and let conda find  the best version worked for me.


Autotools defaults to static libraries

Configure Autotools generate a static lib by default, as this is Hunter's convention
Tested with the odb-sqlite example

Thanks


执行了install,输出有点错误

现在nginx访问页面打得开.似乎安装好了.
Got pyaml 17.8.0.
Getting distribution for 'redis'.
warning: no previously-included files found matching '__pycache__'
warning: no previously-included files matching '*.pyc' found under directory 'tests'
zip_safe flag not set; analyzing archive contents...
Got redis 2.10.6.
Getting distribution for 'gevent'.
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'cffi_modules'
  warnings.warn(msg)
warning: no files found matching 'changelog.rst'
warning: no files found matching 'known_failures.py'
warning: no files found matching '.pep8'
no previously-included directories found matching '*/__pycache__'
warning: no previously-included files matching '*.so' found anywhere in distribution
warning: no previously-included files matching '*.o' found anywhere in distribution
warning: no previously-included files matching '*.lo' found anywhere in distribution
warning: no previously-included files matching '*.la' found anywhere in distribution
warning: no previously-included files matching 'config.log' found anywhere in distribution
warning: no previously-included files matching 'config.status' found anywhere in distribution
no previously-included directories found matching 'doc/_build'
warning: no previously-included files matching '*.pyc' found anywhere in distribution
warning: no previously-included files matching '.coverage' found under directory 'src/greentest'
no previously-included directories found matching 'src/greentest/htmlcov'
warning: no previously-included files matching 'stamp-h?' found under directory 'deps/c-ares'
warning: no previously-included files matching 'ares_build.h.orig' found under directory 'deps/c-ares'
no previously-included directories found matching 'deps/libev/.deps'
warning: no previously-included files matching 'Makefile' found under directory 'deps/libev'
warning: no previously-included files matching 'libtool' found under directory 'deps/libev'
warning: no previously-included files matching 'stamp-h?' found under directory 'deps/libev'
warning: no previously-included files matching 'config.h' found under directory 'deps/libev'
warning: no previously-included files matching '_corecffi.c' found under directory 'src/gevent'
warning: no previously-included files found matching 'Makefile'
warning: no previously-included files found matching 'configure-output'
./configure: line 6318: /usr/bin/file: No such file or directory
In file included from src/gevent/libev/libev.h:2:0,
                 from src/gevent/libev/gevent.corecext.c:434:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:483:48: warning: "/*" within comment [-Wcomment]
 /*#define MIN_INTERVAL  0.00000095367431640625 /* 1/2**20, good till 2200 */
 ^
In file included from src/gevent/libev/libev.h:2:0,
                 from src/gevent/libev/gevent.corecext.c:434:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:1831:31: warning: ‘ev_default_loop_ptr’ initialized and declared ‘extern’
   EV_API_DECL struct ev_loop *ev_default_loop_ptr = 0; /* needs to be initialised to make it a definition despite extern */
                               ^
In file included from src/gevent/libev/libev.h:2:0,
                 from src/gevent/libev/gevent.corecext.c:434:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c: In function ‘ev_io_start’:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:3878:34: warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses]
   fd_change (EV_A_ fd, w->events & EV__IOFDSET | EV_ANFD_REIFY);
                                  ^
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c: At top level:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:5135:27: warning: "/*" within comment [-Wcomment]
 /* EV_STAT     0x00001000 /* stat data changed */
 ^
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:5136:27: warning: "/*" within comment [-Wcomment]
 /* EV_EMBED    0x00010000 /* embedded event loop needs sweep */
 ^
In file included from src/gevent/libev/libev.h:2:0,
                 from src/gevent/libev/gevent.corecext.c:434:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c: In function ‘evpipe_write’:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:2468:11: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-resul
t]
           write (evpipe [1], &counter, sizeof (uint64_t));
           ^
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:2480:11: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-resul
t]
           write (evpipe [1], &(evpipe [1]), 1);
           ^
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c: In function ‘pipecb’:
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:2501:11: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result
]
           read (evpipe [1], &counter, sizeof (uint64_t));
           ^
/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev/ev.c:2515:11: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result
]
           read (evpipe [0], &dummy, sizeof (dummy));
           ^
./configure: line 10001: /usr/bin/file: No such file or directory
In file included from src/gevent/gevent.ares.c:435:0:
src/gevent/dnshelper.c:19:0: warning: "PyUnicode_FromString" redefined
   #define PyUnicode_FromString         PyBytes_FromString
 ^
In file included from /usr/include/python2.7/Python.h:85:0,
                 from src/gevent/gevent.ares.c:4:
/usr/include/python2.7/unicodeobject.h:281:0: note: this is the location of the previous definition
 # define PyUnicode_FromString PyUnicodeUCS4_FromString
 ^
  File "build/bdist.linux-x86_64/egg/gevent/_socket3.py", line 195
    def makefile(self, mode="r", buffering=None, *,
                                                  ^
SyntaxError: invalid syntax

  File "/alarm/eggs/tmpNL6jem/gevent-1.2.2-py2.7-linux-x86_64.egg/gevent/_socket3.py", line 195
    def makefile(self, mode="r", buffering=None, *,
                                                  ^
SyntaxError: invalid syntax

Running '(cd  "/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/libev"  && sh ./configure   && cp config.h "$OLDPWD" ) > configure-output.txt' in /tmp/easy_install-EuLTIE/g
event-1.2.2/build/temp.linux-x86_64-2.7/libev
Running '(cd  "/tmp/easy_install-EuLTIE/gevent-1.2.2/deps/c-ares"  && if [ -r ares_build.h ]; then cp ares_build.h ares_build.h.orig; fi   && sh ./configure --disable
-dependency-tracking CONFIG_COMMANDS=   && cp ares_config.h ares_build.h "$OLDPWD"   && mv ares_build.h.orig ares_build.h) > configure-output.txt' in /tmp/easy_instal
l-EuLTIE/gevent-1.2.2/build/temp.linux-x86_64-2.7/c-ares
Got gevent 1.2.2.
Getting distribution for 'bottle'.
warning: no files found matching 'LICENSE.txt'
zip_safe flag not set; analyzing archive contents...
bottle: module references __file__
bottle: module references __path__
Got bottle 0.12.13.
Getting distribution for 'certifi'.
/usr/local/lib/python2.7/dist-packages/setuptools/dist.py:351: UserWarning: Normalizing '2<IP_ADDRESS>' to '2<IP_ADDRESS>'
  normalized_version,
Got certifi 2<IP_ADDRESS>.
Getting distribution for 'future>=0.16.0'.
warning: no files found matching '*.au' under directory 'tests'
warning: no files found matching '*.gif' under directory 'tests'
warning: no files found matching '*.txt' under directory 'tests'
zip_safe flag not set; analyzing archive contents...
future.backports.test.ssl_servers: module references __file__
future.backports.test.support: module references __file__
future.standard_library.__init__: module references __file__
future.standard_library.__init__: module references __path__
future.utils.__init__: module MAY be using inspect.stack
past.builtins.misc: module MAY be using inspect.stack
past.translation.__init__: module references __file__
past.translation.__init__: module references __path__
Got future 0.16.0.
Getting distribution for 'contextlib2'.
zip_safe flag not set; analyzing archive contents...
Got contextlib2 0.5.5.
Getting distribution for 'urllib3<1.23,>=1.21.1'.
warning: no previously-included files matching '*' found under directory 'docs/_build'
zip_safe flag not set; analyzing archive contents...
urllib3.packages.six: module references __path__
Got urllib3 1.22.
Getting distribution for 'idna<2.7,>=2.5'.
warning: no previously-included files matching '*.pyc' found under directory 'tools'
warning: no previously-included files matching '*.pyc' found under directory 'tests'
zip_safe flag not set; analyzing archive contents...
Got idna 2.6.
Getting distribution for 'chardet<3.1.0,>=3.0.2'.
warning: no files found matching 'requirements.txt'
zip_safe flag not set; analyzing archive contents...
Got chardet 3.0.4.
Getting distribution for 'PyYAML'.
build/temp.linux-x86_64-2.7/check_libyaml.c:2:18: fatal error: yaml.h: No such file or directory
 #include <yaml.h>
                  ^
compilation terminated.

libyaml is not found or a compiler error: forcing --without-libyaml
(if libyaml is installed correctly, you may need to
 specify the option --include-dirs or uncomment and
 modify the parameter include_dirs in setup.cfg)
zip_safe flag not set; analyzing archive contents...
Got PyYAML 3.12.
Getting distribution for 'greenlet>=0.4.10'.

这一些编译错误不影响正常使用的，一个是跟 python3 有关的，python2 的模块是能编译成功的。 另一个是加速 yaml 解析用的，编译失败之后会使用纯 python 方式解析。


Add Large Datapad

Hi,
for my game i need to create large datapad to add more informations to it.
I have create the 2250w png from the one already present in the artwork directory.
It will be great if you can add my modification in your amazing module :)
Thanks

Merged, thanks for the PR!


[WIP] .NET Core 2.2.0 support

Update to .NET Core SDK 2.2.100.
Update tests to target netcoreapp2.2.
Use the new NuGet symbol package format.
Add a .gitattributes file to (hopefully) stop the whitespace shift.

I thought it was just a different package (.snupkg) instead of the current additionally generated symbols file symbols.nupkg. I did link to the same doc in the description.
It's not otherwise changing anything else? There's no PDB files inside the existing .nupkg files from what I can see changing them to .zip and opening them with Windows Explorer.

Ah cool, I didn't realised it was the same page 👍
The current artifacts are a bit misleading, in that we don't actually do anything with the symbols.nupkg files. The DebugType is embedded which means they are portable and embedded into the assembly itself. So we have a russian doll sorta thing which goes nupkg -> assembly -> symbols -> source.
Embedding barely changes the size of the assembly as well, but some purists have convinced Microsoft it's a big enough issue not to be the long term solution. You can tell I'm a bit salty about the decision.

So,merge this after SDK version 2.2.100 is officially out?

It should be safe to merge once the packages get to NuGet.org.


Issue-505: Add a test case for the AesUtils class

Make sure that:

[x] You have read the contribution guidelines.
[x] You submit test cases (unit or integration tests) that back your changes.
[x] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

CipherUtilsTest you haven't done it yet? @HoldDie

CipherUtilsTest you haven't done it yet? @HoldDie

ok, I thought I could only have another one, wait a minute, then I'll make up that, too

Codecov Report

Merging #523 (7a6f821) into master (26e17f7) will increase coverage by 0.34%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #523      +/-   ##
============================================
+ Coverage     15.28%   15.63%   +0.34%
- Complexity      306      316      +10
============================================
  Files           251      251
  Lines          5175     5175
  Branches        489      489
============================================
+ Hits            791      809      +18
+ Misses         4292     4276      -16
+ Partials         92       90       -2

Impacted Files
Coverage Δ
Complexity Δ

.../dromara/soul/common/constant/ZkPathConstants.java
88.88% <0.00%> (ø)
8.00% <0.00%> (ø%)

...java/org/dromara/soul/admin/utils/CipherUtils.java
86.36% <0.00%> (+9.09%)
12.00% <0.00%> (+2.00%)

...va/org/dromara/soul/admin/listener/SoulDomain.java
75.00% <0.00%> (+25.00%)
3.00% <0.00%> (+1.00%)

...in/java/org/dromara/soul/admin/utils/AesUtils.java
57.14% <0.00%> (+28.57%)
4.00% <0.00%> (+2.00%)

...dromara/soul/admin/controller/IndexController.java
100.00% <0.00%> (+66.66%)
2.00% <0.00%> (+1.00%)

...org/dromara/soul/common/enums/ConfigGroupEnum.java
100.00% <0.00%> (+100.00%)
4.00% <0.00%> (+4.00%)

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 26e17f7...7a6f821. Read the comment docs.


Error occurs when i try to import GIF, OS Windows 7

Is it reproducible with every GIF or with special?

I tried to import a gif with indexed palette db16 with original size - all good

sorry, not gif, but png!

Here is my test image

yes, it crashes
will fix

Also, if possible, export/import for Android?

@trelemar it's possible, the problem is that Android doesn't have native file open dialog to open external file
On Android TIC will only save exported .gif to the working folder on export sprites.gif and load from the folder on 'import sprites.gif'.

fixed crash on .gif import

Android export/import will be fixed here #54

test build
tic_fixed_gif_import.zip

Test build works fine!


Please provide more examples for single line comment handling

The example shows this...
{
  "Date": "2019-08-01T00:00:00-07:00",
  "TemperatureCelsius": 25, // Fahrenheit 77
  "Summary": "Hot", /* Zharko */
}

What about these more common forms of comments?
{
  "Date": "2019-08-01T00:00:00-07:00",
  "TemperatureCelsius": 25,
  // "TemperatureFahrenheit": 77,
  "Summary": "Hot",
  /* "OddSummary": "Zharko" */
}

And then what if the json is minified into a single line? Does this feature depend on having CR+| LF in the json?

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

ID: 588ae32f-3429-143f-824c-5ab2d046d24a
Version Independent ID: 002f9f2a-48d1-0671-a079-b99b9f6bab58
Content: How to serialize and deserialize JSON using C# - .NET
Content Source: docs/standard/serialization/system-text-json-how-to.md
Product: dotnet
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

Comments can be on separate lines as shown in your example, and the /* ... */ format works in minified JSON.


[warning] mutating the [[Prototype]] of an object will cause your code to run very slowly

I don't use this package directly (and can't find where it comes from in my system) but I'm always getting this annoying warning in firefox console
mutating the [[Prototype]] of an object will cause your code to run very slowly;
instead create the object with the correct initial [[Prototype]] value using Object.create

and peace of code:

I've found out that it's from mongol package (and I don't need it in production) but anyway. Is this warning ok?

This is a common warning that is raised only by Firefox, when replacing the prototype of an object, there's nothing that can be done about it, except not do that, but then the Meteor.users collection will not work properly.


parse error: Invalid numeric literal at line 1, column 5

Home Assistant 2023.5.3
Supervisor 2023.04.1
Operating System 10.1
Frontend 20230503.3 - latest
Samba Backup 5.2.0
Manual backup did well
Auto backup started at defined timw 1:30, at this same time it reported error but in category INFO
[23-05-16 01:30:13] INFO: Creating backup "Partial Backup 2023-05-16 01:30 (HA 2023.5.3)" parse error: Invalid numeric literal at line 1, column 5
Then he was running the backup and reported finished exactly 3 hours later
[23-05-16 04:30:24] INFO: Backup finished
(should be about 10GB)
Finished but there is no backup file in shared location.

I have the same issue (for a while)...
Used to do Full daily backups to my QNAP via SMB share, stopped working a few weeks ago...
"last_backup":"2023-04-23 23:02"
Home Assistant 2023.5.3
Supervisor 2023.04.1
Operating System 10.1
Frontend 20230503.3 - latest
Samba Backup 5.2.0
this was the logging from last nights backup run:
[23-05-15 20:00:16] INFO: Backup running ...
[23-05-15 20:00:16] DEBUG: Backups local/remote: 0/0
[23-05-15 20:00:16] DEBUG: Total backups succeeded/failed: 212/43
[23-05-15 20:00:16] DEBUG: Last backup: 2023-04-23 23:02
[23-05-15 20:00:16] DEBUG: Posting sensor data to API at /core/api/states/sensor.samba_backup
[23-05-15 20:00:16] DEBUG: API Status: 200
[23-05-15 20:00:16] DEBUG: API Response: {"entity_id":"sensor.samba_backup","state":"RUNNING","attributes":{"friendly_name":"Samba Backup","backups_local":"0","backups_remote":"0","total_backups_succeeded":"212","total_backups_failed":"43","last_backup":"2023-04-23 23:02"},"last_changed":"2023-05-15T18:00:16.969305+00:00","last_updated":"2023-05-15T18:00:16.969305+00:00","context":{"id":"01H0G93XT97WJR924RPN5HBBKX","parent_id":null,"user_id":"580292d0d60b47228d107ba3abe4bb18"}}
[23-05-15 20:00:17] INFO: Creating backup "2023-05-15 20:00 Full 2023.5.3"
parse error: Invalid numeric literal at line 1, column 5
[23-05-15 23:00:17] DEBUG: Posting sensor data to API at /core/api/states/sensor.samba_backup
[23-05-15 23:00:17] DEBUG: API Status: 200
[23-05-15 23:00:17] DEBUG: API Response: {"entity_id":"sensor.samba_backup","state":"FAILED","attributes":{"friendly_name":"Samba Backup","backups_local":"1","backups_remote":"0","total_backups_succeeded":"212","total_backups_failed":"44","last_backup":"2023-04-23 23:02"},"last_changed":"2023-05-15T21:00:17.487899+00:00","last_updated":"2023-05-15T21:00:17.487899+00:00","context":{"id":"01H0GKDH6FJ8HN5DVXZQ799G9K","parent_id":null,"user_id":"580292d0d60b47228d107ba3abe4bb18"}}
[23-05-15 23:00:27] DEBUG: Posting sensor data to API at /core/api/states/sensor.samba_backup
[23-05-15 23:00:27] DEBUG: API Status: 200
[23-05-15 23:00:27] DEBUG: API Response: {"entity_id":"sensor.samba_backup","state":"IDLE","attributes":{"friendly_name":"Samba Backup","backups_local":"1","backups_remote":"0","total_backups_succeeded":"212","total_backups_failed":"44","last_backup":"2023-04-23 23:02"},"last_changed":"2023-05-15T21:00:27.561185+00:00","last_updated":"2023-05-15T21:00:27.561185+00:00","context":{"id":"01H0GKDV1976S0EBMJBD4K9VTN","parent_id":null,"user_id":"580292d0d60b47228d107ba3abe4bb18"}}
[23-05-15 23:00:27] INFO: Backup finished
file was available locally but not on the SMB share... my backup is also around 10GB in size.

#65
check, we both exceed the 3 hours limit. This could be the reason why it stopped working at a sudden time a while ago.
It seems there is currently no solution to overcome this 3 hours limit.

Yes, it looks You are right. I found that backup in HA folder backup.

It seems there is currently no solution to overcome this 3 hours limit.

The creator of this add-on suggest to replace CLI with API calls in [#79]
(https://github.com/thomasmauerer/hassio-addons/issues/79) which should definitely solve the problem. I have no idea how to bite that.

Hi @QbaF
did You found how to replace the CLI calls with API? Also I have the problem with the 3 hours. 😤

same issue. Backup over 13 Gb, I dont understand where the 3 hours come from ?

I'm getting this error too. Only just noticed it. My backups have always taken ages but always thought it's because I set the purge to 90 days, lots of data. Doesn't really bother me as it runs during the night.
Here's the logs:
[23-09-24 03:05:16] INFO: Backup running ...
[23-09-24 03:05:17] INFO: Creating backup "Samba Backup 2023-09-24 03:05"
[23-09-24 06:05:05] INFO: Copying backup ed115259 (Samba_Backup_2023_09_24_03_05.tar) to share
[23-09-24 06:17:04] INFO: Deleting 7160f882 (Samba Backup 2023-09-17 03:05) local
[23-09-24 06:17:05] INFO: Deleting Samba_Backup_2023_07_26_03_05.tar on share
[23-09-24 06:17:16] INFO: Backup finished
[23-09-25 03:05:36] INFO: Backup running ...
[23-09-25 03:05:37] INFO: Creating backup "Samba Backup 2023-09-25 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-09-25 06:05:49] INFO: Backup finished
[23-09-26 03:05:09] INFO: Backup running ...
[23-09-26 03:05:11] INFO: Creating backup "Samba Backup 2023-09-26 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-09-26 06:05:40] INFO: Backup finished
[23-09-27 03:05:00] INFO: Backup running ...
[23-09-27 03:05:01] INFO: Creating backup "Samba Backup 2023-09-27 03:05"
[23-09-27 06:05:18] INFO: Copying backup d52391e4 (Samba_Backup_2023_09_27_03_05.tar) to share
[23-09-27 06:16:57] INFO: Deleting e21ea6fa (Samba Backup 2023-09-20 03:05) local
[23-09-27 06:16:57] INFO: Deleting e2c693dd (Samba Backup 2023-09-19 03:05) local
[23-09-27 06:16:57] INFO: Deleting fa768854 (Samba Backup 2023-09-18 03:05) local
[23-09-27 06:16:58] INFO: Deleting Samba_Backup_2023_07_27_03_05.tar on share
[23-09-27 06:17:09] INFO: Backup finished
[23-09-28 03:05:29] INFO: Backup running ...
[23-09-28 03:05:30] INFO: Creating backup "Samba Backup 2023-09-28 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-09-28 06:06:03] INFO: Backup finished
[23-09-29 03:05:22] INFO: Backup running ...
[23-09-29 03:05:24] INFO: Creating backup "Samba Backup 2023-09-29 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-09-29 06:05:54] INFO: Backup finished
[23-09-30 03:05:14] INFO: Backup running ...
[23-09-30 03:05:16] INFO: Creating backup "Samba Backup 2023-09-30 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-09-30 06:05:49] INFO: Backup finished
[23-10-01 03:05:09] INFO: Backup running ...
[23-10-01 03:05:11] INFO: Creating backup "Samba Backup 2023-10-01 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-10-01 06:05:40] INFO: Backup finished
[23-10-02 03:05:01] INFO: Backup running ...
[23-10-02 03:05:02] INFO: Creating backup "Samba Backup 2023-10-02 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-10-02 06:05:31] INFO: Backup finished
[23-10-03 03:05:51] INFO: Backup running ...
[23-10-03 03:05:53] INFO: Creating backup "Samba Backup 2023-10-03 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-10-03 06:06:22] INFO: Backup finished
[23-10-04 03:05:41] INFO: Backup running ...
[23-10-04 03:05:43] INFO: Creating backup "Samba Backup 2023-10-04 03:05"
parse error: Invalid numeric literal at line 1, column 5
[23-10-04 06:06:12] INFO: Backup finished
[23-10-05 03:05:32] INFO: Backup running ...
[23-10-05 03:05:33] INFO: Creating backup "Samba Backup 2023-10-05 03:05"

Prior to the 24th, the backups look to be running fine, though that maybe a fluke.
Looking at my backups folder, they're all around 7.5Gb. I do have some gaps during Sept, but I know I hit the network cable to the samba server and it was offline at some point.


CUDA out of memory Error - decrease batch size (?)

Hi! I am trying to run the inference.py script with the "testing" inputs, but I'm having memory issues.
I'm running it locally, on a computer with GPU NVIDIA GeForce RTX 3060 (max 8192MiB). I'm using the llama2-7B model.
When I run
python inference.py -i ./testing/input/ -o ./testing/output/
I get the following messages
[nltk_data] Downloading package punkt to /home/manuela/nltk_data...
[nltk_data]   Package punkt is already up-to-date!
[nltk_data] Downloading package stopwords to
[nltk_data]     /home/manuela/nltk_data...
[nltk_data]   Package stopwords is already up-to-date!
Loading checkpoint shards: 100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2/2 [00:07<00:00,  3.57s/it]
WARNING:root:Some parameters are on the meta device device because they were offloaded to the cpu.
WARNING:root:Some parameters are on the meta device device because they were offloaded to the cpu.
Loading BioSent2Vec model
model successfully loaded
start phenogpt
CUDA out of memory. Tried to allocate 500.00 MiB. GPU
Cannot produce results for sample2
CUDA out of memory. Tried to allocate 172.00 MiB. GPU
Cannot produce results for sample1

Is my GPU memory not enough to run this locally? Is there any way you can help me?
Thanks in advance and congratulations on the amazing paper and results!

Hello, thank you so much for using our tool! Unfortunately, I don't think you can be able to run our model on your setup. One way you can reduce the memory usage is to specify "load_8bit=True" in the inference.py script. This allows to run the model with lower precision. However, based on our testing, it requires at least 10GB ~ 9536.74MiB to run the inference if you set "load_8bit=True" and 30GB for "load_8bit=False".
If you have two 8GB GPUs then, the memory usage can be split and you can be able to run it.


error[E0432]: unresolved import reqwest::blocking

When I compile the program using cargo, there are no issues.
However, when I use trunk serve, an error occurs:
error[E0432]: unresolved import reqwest::blocking
I have already added reqwest = { version = "0.11", features = ["blocking", "json"] } in Cargo.toml.
Strangely, yesterday I was able to execute trunk serve

By "program" you mean the web application? You might need to try cargo check --target wasm32-unknown-unknown in that case, it it needs to compile to WASM and not to your default target.
reqwest can't use tokio for wasm, but relies on browser APIs.

I am closing this as I believe there is nothing that trunk can do. We can re-open the issue otherwise.


optionally disable drag-gestures in not-zoomed state

This improves page-swiping in HorizontalPager from accompanist or standard horizontal lists which use Zoomable (e.g. image-galleries).
For that use-case, set the swipeEnabled-parameter to false to disable swipe-gestures in the unzoomed-state for Zoomable (so dragging-gestures in zoomed-state still work).

Also, I'll probably rework this a little so that disabling dragging when zoomed in is possible, too.
You can incorporate that into this PR yourself if you want to, of course.

I changed the PR-target.
Regarding your proposed rework, I am not quite sure how you want it to look like, so I think its better if you do that.


Add follow_redirects for download Windows-Agent on Windows

Description of PR :
Zabbix has set up a redirection to download the zabbix agents for Windows:
(Example with version 3.4.6)
https://www.zabbix.com/downloads/3.4.6/zabbix_agents_3.4.6.win.zip => https://assets.zabbix.com/downloads/3.4.6/zabbix_agents_3.4.6.win.zip
},
"msg": "Moved Temporarily",
"size": 154,
"status_code": 302,
"url": "https://www.zabbix.com/downloads/3.4.6/zabbix_agents_3.4.6.win.zip"

}
Here is the problem encountered :
TASK [dj-wasabi.zabbix-agent : Windows | Unzip file] *****************************************************************************************************************************************************************************************
fatal: [hostname]: FAILED! => {
"changed": false,
"dest": "C:\Zabbix",
"msg": "Error unzipping 'C:\Zabbix\zabbix_agents_3.4.6.win.zip' to 'C:\Zabbix'!. Method: System.IO.Compression.ZipFile, Exception: Exception calling "Open" with "3" argument(s): "End of Central Directory record could not be found."",
"removed": false,
"src": "C:\Zabbix\zabbix_agents_3.4.6.win.zip"
}
It is not possible to unzip the file because it has not been downloaded correctly.
The goal of this PR is to adapt the playbook to be able to download the zabbix agents with this redirection.
Type of change :
Add "follow_redirects: all" to the task : Windows | Download Zabbix Agent Zip file

Thanks! 👍


Update certificate handling for Equinor

New certificates are being issued and the old ones will eventually expire. The existing solution for importing a specific certificate (the old root cert) specified by hash to certifi must therefore be updated. Perhaps amend add_statoil_root_certificate() to support both the old and the new certificate?
I also suggest to consider adding functionality for fetching the certificate directly from pki.equinor.com. That would make things easier for Linux users and others using tagreader in environments without pre-existing Equinor certificates (e.g. Radix).

I think the update of pi webapi certificates just broke tagreader and the add_statoil_root_certificate function

#271


Typing "wt" in Explorer address bar shall open Windows Terminal from the current folder (i.e. "Here")

Description of the new feature/enhancement
Currently if type "wt" in Explorer address bar and press Enter, no matter which folder is currently opened in Explorer, the Windows Terminal will always open in %UserProfile%. Verified in version: 1.0.1401.0
It is expected to go directly to the current folder that is opened in Explorer. Like when you type "cmd" in address bar for the same.

Proposed technical implementation details (optional)

Thanks for the suggestion! Please make sure to search for duplicates when filing new issues. This is already being tracked by another issue on our repo - please refer to #878 for more discussion.
We wanted to make wt behave like cmd or powershell here, but unfortunately, there were just too many odd edge cases to make this work right. There are more details over in https://github.com/microsoft/terminal/issues/878#issuecomment-579508860 if you want more reading. The recommended way to open the terminal in the current directory is by typing wt -d . in the explorer bar.
/dup #878 #6559 #6456 #6279 #6031 #5796


How to exclude the view content set in AndroidViewFilterRender on OpenGlView

I found that the view which set in AndroidViewFilterRender will output the same content on OpenGlView, which may cause some weird behavior because user may see duplicate contents, one with native View, one render from OpenGL.

You can draw it behind openglview. In this case You only see it from opengl.


[Request] add clothing (white shirt) and hairstyle (long hair, bob cut)

Thank you for the useful node.
[Request] Is it possible to add clothes (white shirt) and hairstyle (long hair, bob cut) to the tag filter?
Thank you in advance.

Thank you for your request! Understood, I will add the clothes (white shirt) and hairstyle (long hair, bob cut) to the tag filter.
Thank you in advance for your patience.

Upon checking, it seems that these tags are already added. The difference is in cases like "long hair" where there is a space. In the JSON data, we use underscores instead of spaces (e.g., long_hair).
Currently, there is code that does not differentiate between spaces and underscores, but some code does, leading to inconsistency.
I plan to fix this soon so that it works with both spaces and underscores.
In the meantime, could you try using underscores instead of spaces and see if that works for you?

Thank you for your response.
I tried it with underscores and it worked!
Thanks!


Namespace problem with gii generated code [advanced app]

I followed guide to create advanced app
Idem to enable gii
I'm working in localhost so I used gii from:
http:://localhost/backend/index.php?r=gii

I created CRUD for app\controllers\GroupController, and the file has been created as
backend/controller/GroupController.php

with namespace
namespace app\controllers;

But accessing
http://localhost/backend/web/index.php?r=group

I got
Unknown Class – yii\base\UnknownClassException

 Unable to find 'backend\controllers\GroupController' in file: C:\xampp\htdocs/backend/controllers/GroupController.php. Namespace missing?

If my namespace is really wrong, please modify gii to help newbie users to choose appropriate namespace.
Else, what's wrong?

I actually ran into a similar problem right off the bat when using the advanced template.  I simply wanted to create a new controller, so I copied SiteController.php to NewController.php, and renamed the class (figuring, of course it would work, since SiteController worked fine...), and was subsequently met with
Unable to find 'frontend\controllers\NewController' in file: .../frontend/controllers/NewController.php. Namespace missing?

The solution was to replace namespace app\controllers; with namespace frontend\controllers;.

Gracias PrplHaz4 fue una solución muy sencilla, pero para los que estamos empezando con yii2 nos ayuda bastante.


feature add ip to IntegerType function

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall


[ArPow] Onboard clicommandlineparser to arcade-powered source-build

In progress with https://github.com/dotnet/CliCommandLineParser/pull/177

@crummel, I tried building CliCommandLineParser repo with the ArPow command and encountered some issues.  While investigating I noticed the repo is on Arcade 1.x.  How is ArPow working in this repo?


feat: Add functionality to export doc strings on types

Overview
I added functionality (and tests) to export doc strings on exported types.
Example
/// Doc comment.
/// Supports new lines.
///
/// Testing
#[derive(TS)]
#[ts(export_to = "tests-out/docs/")]
struct A {
    name: String,
}

is exported as
/**
 * Doc comment.
 * Supports new lines.
 *
 * Testing
 */
export interface A { name: string, }

How
This is achieved by parsing the Vec<Attribute> of an the exported type Item by filtering for "doc" , and then passing that data down to the export layer where generate_decl prepends the doc string before the export definition in TypeScript.
Comments

The only thing I am unsure about is how this interacts with the type_def function which is used both for exported types and field types.
Only works with "normal doc comments", not with include_str doc comments or other "doc formats".

Related
#52
#102

Concept ACK. Would love to see this merged
https://github.com/Aleph-Alpha/ts-rs/issues/188

Fixes #188
Just so GitHub tracks the issue with the PR

Thanks for the PR!
The general structure of the PR looks good, though there are some minor problems I'd like to resolve before merging this.

Hey @NyxCode! What are those minor problems? I can take a look when I have time if you want

Hey @NyxCode! What are those minor problems? I can take a look when I have time if you want

oh, seems like i didnt submit the review, sorry.

Well this is annoying, locally editing this PR gets me 131 commits behind main, so tests still expect interface, but on CI they expect type

@timephy, can you merge main into your fork? I tried to do it but it just turns into a PR to your fork

Nevermind, figured out how to do it!
Sorry, still new to managing PRs

Hi!
First of all thank your for refactoring and fixing problems!
I have changed the code to still generate a const DOCS = None field, even if no docs are set on the type.
I use the .docs() or now .DOCS in code of mine, and I rely on its presence, therefore if the field is simply missing (instead of being None) this would lead to errors.

Hi,
First of all, thanks for refactoring the code and solving problems!
Especially that you removed docs from all function calls, and moved it into Attr structs. - This bothered me as well, but I was not sure about how to solve it better at the time.
Note: I made a commit I then realized was unnecessary, because the TS trait already implemented a fallback for the DOCS field. Therefore I removed those changes again.

I believe it is possible to also add docs for struct fields and enum variants... (#188)
Do we want to implement and include this in this PR or implement it somewhen else in another?

Okay, I tried to implement docs for fields+variants as well..
But there were several complications that we need to resolve, I'd like to ask for your help doing that / making the right decisions. I have committed these changes to a separate branch and opened a new PR #228 for that.
I suggest implementing this PR first / implementing the docs for fields/variants in that new PR.
Thanks again for the help/coop!

I believe it is possible to also add docs for struct fields and enum variants

I think struct fields shouldn't be too dificult, but we have to make sure to handle #[ts(flatten)] correctly, which always complicates things
Enum variants are a whole other beast though. They are represented as a type union of the different variants and there is no convenient way to add docs for specific type union members in TS.
We could implement #86 and document each variant type, but at the end of the day, we'd do type Enum = VariantA | VariantB, and when using Enum the docs for VariantA and VariantB would not show up anywhere

Do we want to implement and include this in this PR or implement it somewhen else in another?

Definetly another PR, creating #228 was a good call

I suggest implementing this PR first / implementing the docs for fields/variants in that new PR.

Agreed, since all the changes requested have already been made, I will merge this PR now