stitch.py doesn't seal modules properly

@parmef:

Fix stitch.py, which does not seal module connection properly (helices are distorted and side chains go flying in the air). New library should help not needing rebuild, so simply skipping the interface rebuild should work. Test on new library modules.

Possibly related:
@parmef:

stitcher issue 1 (highest priority)
I have played around with the stitcher and unfortunately I have realized that in many structures there are atoms missing or misplaced, usually side chains but occasionally also backbone. I have collected the examples, with notes and blender and cif files, in atom_errors.tar.gz. Joy please have a look and see if you have any idea of where the problem could be. I have checked the pdb modules and they are fine. This is the most important issue.

It seems to be a problem with stitch.py:blend_residues().
Original purpose of the method was to slightly atoms of the residues close to an interface according to the corresponding double's atom positions. However, something is wrong with the following piece of code (when commented out, the weird atom-throwing effect goes away).
stitch.py:329
for ma in m:
    if m.resname == f.resname:
        # Identical residues should have the same atom positions
        assert ma.name in f
        ma.coord = compute_coord(ma, f[ma.name])
    else:
        # Only modify backbone atoms.
        if ma.name in pdb_utils.BACKBONE_NAMES and \
                ma.name in f:
            ma.coord = compute_coord(ma, f[ma.name])

However, according to @parmef, with Leon's new database and module PDBs, the residue blending should not be necessary. I will try with the new data and see if omitting this part allows generation of good result CIFs.

With the e1.json, newly produced modules + xdb.json without the above blending process yield seemingly good result:
Left: new database + no blending, right: e1.cif provided by @parmef

Regarding missing atoms (e3 and e5), I took a look at darp_j1_d14.pdb residue 165 and darp_NI.pdb residue 48,but couldn't quite understand which one is missing. Could you please elaborate more?
I don't think stitch.py removes any atoms by design, except "dirty" atoms they could be added during relaxation and would be complained about. These are: {'1H', '2H', '3H', 'OXT'}.


Improve how colors are handled

Improves how colors are handled.
Colors are now split in the backend between cct and hsv color and added color mode for tuya

Changes merged in https://github.com/FruitieX/homectl/commit/3988ea681aa0f054b86126632d0e1ce7fd915063


Color and Temperature BUG in Apple Home App

Hi, i have a Problem. I am using this WIFi Controller: https://a.aliexpress.com/_BT90Tq
Wifi 5 kanäle RGBW/WW/CW led controller 16 Millionen farben smartphone control musik und timer modus magie hause wifi controller
And this LED Strip: https://a.aliexpress.com/_BSpNG4
Dual Farbe CRI> 95 SMD2835 CCT Dimmbare LED Streifen Licht 24 V DC WW CW farbe Temperatur Einstellbare Flexible LED-Band band
Here are the Last lines of my „App Log“. I hope that us useful:
2020-12-30 09:51:50 DEBUG InstancePluginManager.reportStatus():1180 : Report plugins: [HomeManager.Plugin(scope: nil, name: "homebridge-magichome-dynamic-platform", path: Optional("homebridge-magichome-dynamic-platform"), alias: Optional("homebridge-magichome-dynamic-platform"), installedVersion: Optional("1.9.2"), availableVersion: Optional("1.9.2"), icon: nil, description: Optional("Dynamically adds MagicHome Bulbs and controllers."), homepage: nil, authorName: nil, availableVersionDate: Optional(2020-12-13 17:18:22 +0000), schema: Optional(HomeManager.JSONSchema), type: HomeManager.Plugin.PluginTypes.platform, keywords: Optional(["homebridge-plugin", "hoobs", "magichome", "magic", "home", "lednet", "Magic Home", "magic home", "outlet", "dimmer", "rgb", "rgbw", "rgbww", "LEDnet", "wowled", "flux_led", "smart lights"]), readmeMarkdownString: nil, certified: Optional(false))
Here is my description of the bug:
My LED Stripes are only warm white and cool white and in the „Magic Home App (picture 1) you can see the correct Control options. In Apples Home App i have the wrong controll options, for a RGBW LED Strips (picture 2,3) and not for ww and cw LED Strips only.
I think my WiFi Controller is Not supported till now. It would be very nice, of you Coups help me, that my Control options in the Apple Home App looks correct, like in picture 4 and 5, without the options to control the RGB colors :)
My Setup:

Rasperry Pi 4
HOOBS Version 3.3.1
Homemanager App <IP_ADDRESS>
iPhone 11 Pro Max with iOS 14.2
Magic Home App 1.5.2 (build 80)

Here my pictures to my description:
Picture 1:

Picture 2:

Picture 3:

Picture 4:

Picture 5:

@migudev96
Hello. Thank you for bringing this to my attention.
The good news is that your device is already supported. Moving the reticle to the middle will allow you to control and mix the warm white and cold white LEDs. Take a look at the readme to see how to do that. If you tell Siri "set my lights to warm white" or "set my lights to cool white" the lights will change accordingly but not mixed.
Right now, the "temperature" wheel is non functional and will not change the white brightness correctly. This is actually something we are working on for a future update but I can't say as to how soon.
Let me know if you are able to get your white LEDs functional.

Hello thank you very much. Now i can controll my LED‘s with the Home App on my iPhone, but the colors are shown still wrong. Because this, i can not controll the brightness or the color with Siri.
This Color is warm white with a hue of 0° or 360° (Colorcode FFE5E5)

and this is cold white with a hue of 180° (Colorcode E5FFFF)

.
The range between 0° to 179° and 181° to to 359° is mixed between ww to cw and cw to ww.
The Temperature wheel is functional correct, but only at the 100% Warm White range, the LED‘s go OFF.

It would be very nice if you can fix this. Maybe, that i have the option in the Magic Home Dynamic Plugin on Homebridge, to conigurate that i use a RGB, a RGBWW or a CCT LED Strip, that the colors and temperatures are shown right in Apples Home App and that i am able to controll this about Siri.
Thank you very much and best regards
Miguel

Hello thank you very much. Now i can controll my LED‘s with the Home App on my iPhone, but the colors are shown still wrong. Because this, i can not controll the brightness or the color with Siri.
This Color is warm white with a hue of 0° or 360° (Colorcode FFE5E5) (picture 1) and this is cold white with a hue of 180° (Colorcode E5FFFF) (picture 2).
The range between 0° to 179° and 181° to to 359° is mixed between ww to cw and cw to ww.
The Temperature wheel is functional correct, but only at the 100% Warm White range, the LED‘s go OFF.
It would be very nice if you can fix this. Maybe, that i have the option in the Magic Home Dynamic Plugin on Homebridge, to conigurate that i use a RGB, a RGBWW or a CCT LED Strip, that the colors and temperatures are shown right in Apples Home App and that i am able to controll this about Siri. (Picture 3)
Thank you very much and best regards
Miguel
Picture 1:
[cid:5EA403EE-7225-4BDE-8A38-D3F9ACF6A284-L0-001]
Picture 2:
[cid:2E2864C8-7F4F-42AC-9A77-26B00E0F4338-L0-001]
Picture 3:
[cid:D1004FA1-18B1-475A-B2B8-0ED05A2ABA01-L0-001]
Am 30.12.2020 um 17:34 schrieb Zacknetic<EMAIL_ADDRESS>
@migudev96https://github.com/migudev96
Hello. Thank you for bringing this to my attention.
The good news is that your device is already supported. Moving the reticle to the middle will allow you to control and mix the warm white and cold white LEDs. Take a look at the readme to see how to do that. If you tell Siri "set my lights to warm white" or "set my lights to cool white" the lights will change accordingly but not mixed.
Right now, the "temperature" wheel is non functional and will not change the white brightness correctly. This is actually something we are working on for a future update but I can't say as to how soon.
Let me know if you are able to get your white LEDs functional.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-752683149, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU6IULHWVAVTYR6LFG3SXNJAJANCNFSM4VODRRBQ.
[X][X][X]

The reason why the LEDs turn off is because you are using your RGB+CCT controller to control 2/5 channels. The controller reports to my plugin that it is a 5 channel device and my plugin treats it as such.
You should not use the temperature wheel as it is not supported at this moment. Only use the color wheel.
You should be able to control brightness using the brightness slider in HomeKit.
Are all of your magichome devices using white LEDs? If so, send me your config.json and I will edit it so the color wheel works as a "white only" wheel.
Lastly, I highly suggest you purchase some 5 channel RGB+CCT LED strips so you can avoid this issue and take advantage of our upcoming "adaptive lighting" feature.

Yes, i use only 2/5 channels, but in the Magic Home App i am asked at the beginning, how i connected the Controller.
In my apartment, i have a Setup with about 40m LED Strips with 11 WiFi Controllers. It was about a week of work to bring the LEDs in place and i soldered the wires of some LED‘s from Point to Point direct on the Strips. So for me it is not an option to change them to RGB+CCT LEDs.
In the Magic Home App all my devices are using only CCT LEDs. It would be very nice of you, when you can edit my config.json, that it works like a „white only“ wheel.
Thank you very much. 🙏
I hope, this is the right config.json. I clicked to Advanced, because in the plugin itself, i only have the normal coniguration options like in the picture.
{
"server": {

    "origin": "*",

    "home_setup_id": "X-HM://0023ISYWYE4PM",

    "polling_seconds": 1,

    "port": 80,

    "autostart": 0

},

"client": {

    "country_code": "DE",

    "locale": "de",

    "default_route": "status",

    "theme": "hoobs-dark",

    "temp_units": "celsius",

    "inactive_logoff": 30,

    "postal_code": "50129"

},

"bridge": {

    "username": "6A:25:D8:F6:8B:C7",

    "name": "Homebridge",

    "port": 51826,

    "pin": "031-45-154"

},

"description": "",

"ports": {},

"accessories": [],

"platforms": [

    {

        "plugin_map": {

            "plugin_name": "homebridge-magichome-dynamic-platform"

        },

        "advancedOptions": {

            "namesWithMacAddress": false

        },

        "platform": "homebridge-magichome-dynamic-platform",

        "whiteEffects": {

            "colorWhiteThreshold": 10,

            "simultaniousDevicesColorWhite": true,

            "colorWhiteThresholdSimultaniousDevices": 50,

            "colorOffThresholdSimultaniousDevices": 5

        },

        "pruning": {

            "pruneAllAccessoriesNextRestart": false,

            "restartsBeforeMissingAccessoriesPruned": 3,

            "pruneMissingCachedAccessories": false

        },

        "deviceManagement": {

            "blacklistOrWhitelist": "blacklist",

            "blacklistedUniqueIDs": []

        }

    }

]

}
[cid:187E3234-CA24-497B-9296-D110698C7E74-L0-001]
Best regards and thank you very much for your help.
Miguel
Am 31.12.2020 um 20:39 schrieb Zacknetic<EMAIL_ADDRESS>
The reason why the LEDs turn off is because you are using your RGB+CCT controller to control 2/5 channels. The controller reports to my plugin that it is a 5 channel device and my plugin treats it as such.
You should not use the temperature wheel as it is not supported at this moment. Only use the color wheel.
You should be able to control brightness using the brightness slider in HomeKit.
Are all of your magichome devices using white LEDs? If so, send me your config.json and I will edit it so the color wheel works as a "white only" wheel.
Lastly, I highly suggest you purchase some 5 channel RGB+CCT LED strips so you can avoid this issue and take advantage of our upcoming "adaptive lighting" feature.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753036451, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU4IQPWAQDIG7EEAGXLSXTHN5ANCNFSM4VODRRBQ.

Yes, i use only 2/5 channels, but in the Magic Home App i am asked at the beginning, how i connected the Controller.
In my apartment, i have a Setup with about 40m LED Strips with 11 WiFi Controllers. It was about a week of work to bring the LEDs in place and i soldered the wires of some LED‘s from Point to Point direct on the Strips. So for me it is not an option to change them to RGB+CCT LEDs.
In the Magic Home App all my devices are using only CCT LEDs. It would be very nice of you, when you can edit my config.json, that it works like a „white only“ wheel.
Thank you very much. 🙏
I hope, this is the right config.json. I clicked to Advanced, because in the plugin itself, i only have the normal coniguration options like in the picture.
{
"server": {

    "origin": "*",

    "home_setup_id": "X-HM://0023ISYWYE4PM",

    "polling_seconds": 1,

    "port": 80,

    "autostart": 0

},

"client": {

    "country_code": "DE",

    "locale": "de",

    "default_route": "status",

    "theme": "hoobs-dark",

    "temp_units": "celsius",

    "inactive_logoff": 30,

    "postal_code": "50129"

},

"bridge": {

    "username": "6A:25:D8:F6:8B:C7",

    "name": "Homebridge",

    "port": 51826,

    "pin": "031-45-154"

},

"description": "",

"ports": {},

"accessories": [],

"platforms": [

    {

        "plugin_map": {

            "plugin_name": "homebridge-magichome-dynamic-platform"

        },

        "advancedOptions": {

            "namesWithMacAddress": false

        },

        "platform": "homebridge-magichome-dynamic-platform",

        "whiteEffects": {

            "colorWhiteThreshold": 10,

            "simultaniousDevicesColorWhite": true,

            "colorWhiteThresholdSimultaniousDevices": 50,

            "colorOffThresholdSimultaniousDevices": 5

        },

        "pruning": {

            "pruneAllAccessoriesNextRestart": false,

            "restartsBeforeMissingAccessoriesPruned": 3,

            "pruneMissingCachedAccessories": false

        },

        "deviceManagement": {

            "blacklistOrWhitelist": "blacklist",

            "blacklistedUniqueIDs": []

        }

    }

]

}
[cid:187E3234-CA24-497B-9296-D110698C7E74-L0-001]
Best regards and thank you very much for your help.
Miguel
Am 31.12.2020 um 20:39 schrieb Zacknetic<EMAIL_ADDRESS>
The reason why the LEDs turn off is because you are using your RGB+CCT controller to control 2/5 channels. The controller reports to my plugin that it is a 5 channel device and my plugin treats it as such.
You should not use the temperature wheel as it is not supported at this moment. Only use the color wheel.
You should be able to control brightness using the brightness slider in HomeKit.
Are all of your magichome devices using white LEDs? If so, send me your config.json and I will edit it so the color wheel works as a "white only" wheel.
Lastly, I highly suggest you purchase some 5 channel RGB+CCT LED strips so you can avoid this issue and take advantage of our upcoming "adaptive lighting" feature.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753036451, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU4IQPWAQDIG7EEAGXLSXTHN5ANCNFSM4VODRRBQ.

Hey there,
try changing the following code from
     "colorWhiteThresholdSimultaniousDevices": 50,
to
     "colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any color LEDs, you must change it back, else the color will not activate at all.
The feature to choose your LED type in the MagicHome App is really cool. Unfortunately MagicHome, in their infinite wisdom, does not share that information with me when I poll the device. So the change will have to be manual on your end, eventually.
If this config.json change works out, I will change this issue to a feature request for a functioning color-temperature wheel. Additionally a system for removing the color wheel. How do you feel about renaming the light in HomeKit to set it to CCT only? e.g. changing window light to window light CCT will cause the light to show up as CCT only in HK. After the change, I think I can remove the "CCT" from the name automatically. This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a HOOBS user, I am happy to accommodate you. When I can begin work on this will be determined by how long it takes me to finish the other roadmap features and how much time I can work on this project. Which is loosely based on how much funding I receive / month (though to be honest I put most of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.

Hey there,
try changing the following code from
     "colorWhiteThresholdSimultaniousDevices": 50,
to
     "colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any color LEDs, you must change it back, else the color will not activate at all.
The feature to choose your LED type in the MagicHome App is really cool. Unfortunately MagicHome, in their infinite wisdom, does not share that information with me when I poll the device. So the change will have to be manual on your end, eventually.
If this config.json change works out, I will change this issue to a feature request for a functioning color-temperature wheel. Additionally a system for removing the color wheel. How do you feel about renaming the light in HomeKit to set it to CCT only? e.g. changing window light to window light CCT will cause the light to show up as CCT only in HK. After the change, I think I can remove the "CCT" from the name automatically. This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a HOOBS user, I am happy to accommodate you. When I can begin work on this will be determined by how long it takes me to finish the other roadmap features and how much time I can work on this project. Which is loosely based on how much funding I receive / month (though to be honest I put most of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.

Hi,
I tried, but at the end i changed it back to 50 because there i know which color i have to choose that it is complete warm white and cool white.
My setup with my LED’s in my apartment is complete. At the moment it is not in my plans, to buy any color LED‘s.
To choose it manual with the writing CCT in the Name of the device in the HomeKit App would be very cool and would be very easy. And when the writing CCT is automatically removed, than it would be very great.
A feature request for the color-temperature wheel is that, what i wish for my setup. That there is only shown white colors.
Because the acutal Color wheel, there are many errors in my automation-system, because after the lights where controlled from an automation the color is alaways set up to red in the color temperature wheel, so my lights turn off, and because this I can not make automations with my lights.
How can I make a feature request and how can I help you to make this feature working?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any color LEDs, you must change it back, else the color will not activate at all.
The feature to choose your LED type in the MagicHome App is really cool. Unfortunately MagicHome, in their infinite wisdom, does not share that information with me when I poll the device. So the change will have to be manual on your end, eventually.
If this config.json change works out, I will change this issue to a feature request for a functioning color-temperature wheel. Additionally a system for removing the color wheel. How do you feel about renaming the light in HomeKit to set it to CCT only? e.g. changing window light to window light CCT will cause the light to show up as CCT only in HK. After the change, I think I can remove the "CCT" from the name automatically. This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a HOOBS user, I am happy to accommodate you. When I can begin work on this will be determined by how long it takes me to finish the other roadmap features and how much time I can work on this project. Which is loosely based on how much funding I receive / month (though to be honest I put most of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ.

Hi,
I tried, but at the end i changed it back to 50 because there i know which color i have to choose that it is complete warm white and cool white.
My setup with my LED’s in my apartment is complete. At the moment it is not in my plans, to buy any color LED‘s.
To choose it manual with the writing CCT in the Name of the device in the HomeKit App would be very cool and would be very easy. And when the writing CCT is automatically removed, than it would be very great.
A feature request for the color-temperature wheel is that, what i wish for my setup. That there is only shown white colors.
Because the acutal Color wheel, there are many errors in my automation-system, because after the lights where controlled from an automation the color is alaways set up to red in the color temperature wheel, so my lights turn off, and because this I can not make automations with my lights.
How can I make a feature request and how can I help you to make this feature working?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any color LEDs, you must change it back, else the color will not activate at all.
The feature to choose your LED type in the MagicHome App is really cool. Unfortunately MagicHome, in their infinite wisdom, does not share that information with me when I poll the device. So the change will have to be manual on your end, eventually.
If this config.json change works out, I will change this issue to a feature request for a functioning color-temperature wheel. Additionally a system for removing the color wheel. How do you feel about renaming the light in HomeKit to set it to CCT only? e.g. changing window light to window light CCT will cause the light to show up as CCT only in HK. After the change, I think I can remove the "CCT" from the name automatically. This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a HOOBS user, I am happy to accommodate you. When I can begin work on this will be determined by how long it takes me to finish the other roadmap features and how much time I can work on this project. Which is loosely based on how much funding I receive / month (though to be honest I put most of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ.

Hey there,
How can i make a Feature request and help you to solve my problem with the writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any color LEDs, you must change it back, else the color will not activate at all.
The feature to choose your LED type in the MagicHome App is really cool. Unfortunately MagicHome, in their infinite wisdom, does not share that information with me when I poll the device. So the change will have to be manual on your end, eventually.
If this config.json change works out, I will change this issue to a feature request for a functioning color-temperature wheel. Additionally a system for removing the color wheel. How do you feel about renaming the light in HomeKit to set it to CCT only? e.g. changing window light to window light CCT will cause the light to show up as CCT only in HK. After the change, I think I can remove the "CCT" from the name automatically. This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a HOOBS user, I am happy to accommodate you. When I can begin work on this will be determined by how long it takes me to finish the other roadmap features and how much time I can work on this project. Which is loosely based on how much funding I receive / month (though to be honest I put most of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ.

Hey there,
How can i make a Feature request and help you to solve my problem with the writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any color LEDs, you must change it back, else the color will not activate at all.
The feature to choose your LED type in the MagicHome App is really cool. Unfortunately MagicHome, in their infinite wisdom, does not share that information with me when I poll the device. So the change will have to be manual on your end, eventually.
If this config.json change works out, I will change this issue to a feature request for a functioning color-temperature wheel. Additionally a system for removing the color wheel. How do you feel about renaming the light in HomeKit to set it to CCT only? e.g. changing window light to window light CCT will cause the light to show up as CCT only in HK. After the change, I think I can remove the "CCT" from the name automatically. This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a HOOBS user, I am happy to accommodate you. When I can begin work on this will be determined by how long it takes me to finish the other roadmap features and how much time I can work on this project. Which is loosely based on how much funding I receive / month (though to be honest I put most of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ.

I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

Okay thank you very much for changing it.
Where I can see all the feature requests?
It would be very nice, and I would be very happy to be your alpha tester and to tell you how your code works, but i have no experience in coding javascript/typescript or something else.
Best regards
Miguel
Am 06.01.2021 um 23:10 schrieb Zacknetic<EMAIL_ADDRESS>
I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755744222, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDUY7UWFEAK6KWCL2N2LSYTNVRANCNFSM4VODRRBQ.

Okay thank you very much for changing it.
Where I can see all the feature requests?
It would be very nice, and I would be very happy to be your alpha tester and to tell you how your code works, but i have no experience in coding javascript/typescript or something else.
Best regards
Miguel
Am 06.01.2021 um 23:10 schrieb Zacknetic<EMAIL_ADDRESS>
I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755744222, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDUY7UWFEAK6KWCL2N2LSYTNVRANCNFSM4VODRRBQ.

Okay thank you very much for changing it.
Where I can see all the feature requests?
It would be very nice, and I would be very happy to be your alpha tester and to tell you how your code works, but i have no experience in coding javascript/typescript or something else.
Best regards
Miguel
Am 06.01.2021 um 23:10 schrieb Zacknetic<EMAIL_ADDRESS>
I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755744222, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDUY7UWFEAK6KWCL2N2LSYTNVRANCNFSM4VODRRBQ.

Okay thank you very much for changing it.
Where I can see all the feature requests?
It would be very nice, and I would be very happy to be your alpha tester and to tell you how your code works, but i have no experience in coding javascript/typescript or something else.
Best regards
Miguel
Am 06.01.2021 um 23:10 schrieb Zacknetic<EMAIL_ADDRESS>
I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755744222, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDUY7UWFEAK6KWCL2N2LSYTNVRANCNFSM4VODRRBQ.

Hello Zacknetic,
Where I can see all the feature requests?
It would be very nice, and I would be very happy to be your alpha tester and to tell you how your code works, but i have no experience in coding javascript/typescript or something else.
Best regards
Miguel
Am 06.01.2021 um 23:10 schrieb Zacknetic<EMAIL_ADDRESS>
I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755744222, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDUY7UWFEAK6KWCL2N2LSYTNVRANCNFSM4VODRRBQ.

Hello Zacknetic,
Where I can see all the feature requests?
It would be very nice, and I would be very happy to be your alpha tester and to tell you how your code works, but i have no experience in coding javascript/typescript or something else.
Best regards
Miguel
Am 06.01.2021 um 23:10 schrieb Zacknetic<EMAIL_ADDRESS>
I will change this to a feature request now, however I cannot say when this
feature will be completed as I complete the features in the order that they
are added.
In terms of what you can do, eventually when I begin working on this
feature I will ask you to test it in an alpha version of the plugin.
Alternatively, if you have any experience writing typescript/javascript I
am open to pull requests so feel free to write some code and I will review
it.
On Wed, Jan 6, 2021 at 5:06 PM migudev96<EMAIL_ADDRESS>wrote:

Hey there,
How can i make a Feature request and help you to solve my problem with the
writing CCT behind the Name of the LED in Apple Home Kit?
Best regards
Miguel
Am 01.01.2021 um 20:47 schrieb Zacknetic<EMAIL_ADDRESS>
Hey there,
try changing the following code from
"colorWhiteThresholdSimultaniousDevices": 50,
to
"colorWhiteThresholdSimultaniousDevices": 100,
Keep in mind, this is a global change, so if you do end up purchasing any
color LEDs, you must change it back, else the color will not activate at
all.
The feature to choose your LED type in the MagicHome App is really cool.
Unfortunately MagicHome, in their infinite wisdom, does not share that
information with me when I poll the device. So the change will have to be
manual on your end, eventually.
If this config.json change works out, I will change this issue to a
feature request for a functioning color-temperature wheel. Additionally a
system for removing the color wheel. How do you feel about renaming the
light in HomeKit to set it to CCT only? e.g. changing window light to
window light CCT will cause the light to show up as CCT only in HK. After
the change, I think I can remove the "CCT" from the name automatically.
This is something I can add to the roadmap.
Feature requests are reserved for GitHub Sponsors and HOOBS users. So as a
HOOBS user, I am happy to accommodate you. When I can begin work on this
will be determined by how long it takes me to finish the other roadmap
features and how much time I can work on this project. Which is loosely
based on how much funding I receive / month (though to be honest I put most
of my spare time into this project regardless of funding).
Let me know how the change works out for you. Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-753373489>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/ASJTDU36ZHLIHXWDQRD2DT3SXYRGLANCNFSM4VODRRBQ>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755742183,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABLCJV6DDUFD3MRETKKVBPTSYTNF7ANCNFSM4VODRRBQ
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-755744222, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDUY7UWFEAK6KWCL2N2LSYTNVRANCNFSM4VODRRBQ.

I have received your message the first time.

I have received your message the first time.

Please visit our discord, and let me know that you've joined. I will promote you and that will give you access to the roadmap.
https://discord.gg/c8xpmZSNZC

Please visit our discord, and let me know that you've joined. I will promote you and that will give you access to the roadmap.
https://discord.gg/c8xpmZSNZC

Okay. I thought you forgot me :)
Thank you. I will join now.
Best regards
Miguel
Am 18.01.2021 um 21:35 schrieb Zacknetic<EMAIL_ADDRESS>
Please visit our discord, and let me know that you've joined. I will promote you and that will give you access to the roadmap.
https://discord.gg/c8xpmZSNZC
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-762459511, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU4EIPTWEDUO6BDV4TLS2SLP7ANCNFSM4VODRRBQ.

Okay. I thought you forgot me :)
Thank you. I will join now.
Best regards
Miguel
Am 18.01.2021 um 21:35 schrieb Zacknetic<EMAIL_ADDRESS>
Please visit our discord, and let me know that you've joined. I will promote you and that will give you access to the roadmap.
https://discord.gg/c8xpmZSNZC
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Zacknetic/HomebridgeMagicHome-DynamicPlatform/issues/77#issuecomment-762459511, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASJTDU4EIPTWEDUO6BDV4TLS2SLP7ANCNFSM4VODRRBQ.


cargo build during a docker build takes forever and blows up memory on "Updating crates.io index"

Problem
In my Dockerfile I have this:
FROM python:3.9

RUN echo 'APT::Install-Recommends "false";' > /etc/apt/apt.conf.d/99no-install-recommends
RUN apt-get update \
    && apt-get install -y --no-install-recommends git curl \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
RUN git clone https://github.com/twilight-rs/http-proxy.git
RUN cd http-proxy \
    && . $HOME/.cargo/env \
    && cargo build --release

And just this causes building the image to blow up on the cargo build --release command. It looks like the process gets stuck on the "Updating crates.io index" step forever until the docker container runs out of memory and kills it with exit code 137.
I had to up my docker's vm to 20 GB just to get the command to execute properly. Building this library outside of docker works just fine, takes up almost no memory, and executes in mere seconds.

macOS 12.4
Docker version 20.10.12, build e91ed57
Docker desktop version 4.2.0 (74594)

Steps
docker buildx build --platform linux/amd64 .

Possible Solution(s)
There must be some kind of networking configuration or bypass that can be done here? Why on earth does this work fine on my local machine, but blow up inside of docker build?
Notes
No response
Version
cargo 1.61.0 (a028ae4 2022-04-29)
release: 1.61.0
commit-hash: a028ae42fc1376571de836be702e840ca8e060c2
commit-date: 2022-04-29
host: aarch64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: OracleLinux 11.0.0 [64-bit]

Note that I also a bajillion log lines in the build log saying:
<jemalloc>: MADV_DONTNEED does not work (memset will be used instead)
<jemalloc>: (This is the expected behaviour if you are running under QEMU)

I have seen this same behavior on arm64 docker image builds using docker buildx and qemu. Not sure what a valid workaround is.

https://github.com/keenanjohnson/ros2_rust_workspace/issues/21

Yep, definitely seems like a very similar, if not the same issue! In my case I'm wondering if a workaround could be pre-building/vendoring the cargo library and just copying it into the docker image 🤷🏻♀

Updating crates.io index"

On your machine, it is incrementally updating the registry repo.  On a docker image, it is doing that from scratch.    If it is the act of pulling the registry that is causing things to blow up, you might be interested in https://blog.rust-lang.org/2022/06/22/sparse-registry-testing.html which causes us to only download exactly what is needed.

@epage You are an absolute gem!
Tested and working flawlessly. Diff:
-RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
+RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain nightly
 RUN git clone https://github.com/twilight-rs/http-proxy.git
 RUN cd http-proxy \
     && . $HOME/.cargo/env \
-    && cargo +nightly build --release
+    && cargo +nightly build --release -Z sparse-registry

I also noticed an improvement in the build process by doing:
DOCKER_BUILDKIT=0 docker buildx build --ulimit nofile=1024000:1024000 --platform linux/amd64 .

I do still get the jemalloc warnings and the actual build process is pretty slow (maybe because of these warnings?)... but at least that's totally resolved the memory explosion issue.

Thanks for the great new feature! I'll try out that sparse nightly update and see if it resolves my issue as well!

Sorry I'm a bit new to the nightly builds of cargo, but when I try the docker commands below, I get a  /bin/sh: 1: cargo: not found  error
RUN RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain nightly
ENV PATH=/root/.cargo/bin:$PATH

# Install the cargo-ament-build plugin
RUN cargo +nightly install -Z sparse-registry --debug cargo-ament-build

What thing am I obviously missing and thank you for helping a newbie.

Nvm I was able to figure it out via the following:
# Install Rust
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain 1.61.0 -y
ENV PATH=/root/.cargo/bin:$PATH

# Switch Rust to the nightly bui
RUN rustup toolchain install nightly

# Install the cargo-ament-build plugin
RUN cargo +nightly install -Z sparse-registry --debug cargo-ament-build

Note this feature is awesome and has fixed a long-standing problem with cargo on arm64 for me! I'll leave some feedback in the forum thread, but I hope to see this get mainline @epage !
Sorry for hi-jacking the issue here @lexicalunit !

I'm a bit confused about the setup, can you clarify a few things?
You mention running on macOS?  I'm guessing this is an aarch64 (apple silicon) machine?
If so, is there a particular reason you are running your docker image with amd64? My understanding is that the qemu emulation with Docker in that setup is likely not to work very well.  Is it possible to use an aarch64 linux image instead?

I'm deploying to a linux/amd64 system, but my personal laptop where I'm deploying from is a M1 mac.

If you are just using docker to build something that is then deployed elsewhere, then I might suggest using an aarch64 linux image, and cross-compiling to x86_64. If I understand how Docker on macOS M1 works, that will not run under emulation. I believe it shouldn't be too difficult to install all the requisite cross-toolchain stuff in Debian, though I'm not sure.

@ehuss I don't understand what you mean. I'm already selecting the platform with --platform linux/amd64. My base image is python:3.9 (see https://hub.docker.com/_/python). Are you suggesting I modify my FROM python:3.9 to FROM --platform=linux/amd64 python:3.9? Does that even do anything at all? My assumption would be that this has the same effect as including --platform linux/amd64 in the command line.
I also tested this suggestion and it seems to have no effect.

I'm not familiar with Docker on M1, but I would guess that using --platform arm64v8 or FROM arm64v8/python:3 would fetch the aarch64 image. I don't know if those will run natively, but I would give it a try. Then, inside that arm image, use cargo build --target x86_64-unknown-linux-gnu to cross-compile to amd64 (after installing the requisite cross toolchain stuff).

So on macOS the Docker VM is already running aarch64 Linux AFAIK:
$ nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock .
/ # uname -a
Linux docker-desktop 5.10.76-linuxkit #1 SMP PREEMPT Mon Nov 8 11:22:26 UTC 2021 aarch64 Linux

The only want I know of to specify the platform in the FROM statement of a Dockerfile is via adding --platform=xxx to it.
It's just that I'm running the docker CLI from a M1 terminal, so I need to specify linux/amd64 since that is no longer the default in that context.
I wouldn't want to do --platform arm64v8 because then I'd be building a image with Python built for arm64v8. I need to deploy to a amd64 machine.

I wouldn't want to do --platform arm64v8 because then I'd be building a image with Python built for arm64v8. I need to deploy to a amd64 machine.

My suggestion is to use the --target flag to target x86_64 using cross-compilation. Most Linux package managers support installing packages to help with cross-compiling. It's not clear if you have other requirements that make that difficult. Overall I would suggest avoiding qemu if at all possible.
I believe this is a duplicate of #10583, so closing in favor of that.

I believe the --target option is to target a build stage, not as a pass-thru to compiler flags:
$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      [...]
      --platform string         Set platform if server is multi-platform capable
      [...]
      --target string           Set the target build stage to build.

Unless you mean that I should pass it thru to the cargo build command, like so: cargo +nightly build --target x86_64 [...]? In that case it causes an unrecoverable exception to occur:
 => ERROR [ 6/17] RUN cd http-proxy     && . $HOME/.cargo/env     && cargo +nightly build --target x86_64 --release -Z sparse-registry                                                                                2.3s
------
 > [ 6/17] RUN cd http-proxy     && . $HOME/.cargo/env     && cargo +nightly build --target x86_64 --release -Z sparse-registry:
#10 2.242 error: failed to run `rustc` to learn about target-specific information
#10 2.242
#10 2.242 Caused by:
#10 2.243   process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --target x86_64 --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit status: 1)
#10 2.243   --- stderr
#10 2.243   <jemalloc>: MADV_DONTNEED does not work (memset will be used instead)
#10 2.243   <jemalloc>: (This is the expected behaviour if you are running under QEMU)
#10 2.243   error: Error loading target specification: Could not find specification for target "x86_64". Run `rustc --print target-list` for a list of built-in targets
#10 2.243
------
error: failed to solve: executor failed running [/bin/sh -c cd http-proxy     && . $HOME/.cargo/env     && cargo +nightly build --target x86_64 --release -Z sparse-registry]: exit code: 101

I do still get the jemalloc warnings and the actual build process is pretty slow (maybe because of these warnings?)... but at least that's totally resolved the memory explosion issue.

@lexicalunit you solved this? The build takes extremely long.

In case someone might stumble on this issue and not be satisfied with the suggestion of using nightly, this answer solved it for me: https://users.rust-lang.org/t/cargo-uses-too-much-memory-being-run-in-qemu/76531/2
➡ Add  --config net.git-fetch-with-cli=true to your cargo build command.

@simgt Just make sure if you are using a base image without git, the command will fail:
 => ERROR [builder  9/11] RUN cargo build --config net.git-fetch-with-cli=true --target x86_64-unknown-linux-musl --release                                           2.3s
------
 > [builder  9/11] RUN cargo build --config net.git-fetch-with-cli=true --target x86_64-unknown-linux-musl --release:
#0 1.806     Updating crates.io index
#0 2.291 error: Unable to update registry `crates-io`
#0 2.291
#0 2.291 Caused by:
#0 2.291   failed to fetch `https://github.com/rust-lang/crates.io-index`
#0 2.291
#0 2.291 Caused by:
#0 2.291   could not execute process `git fetch --force --update-head-ok 'https://github.com/rust-lang/crates.io-index' '+HEAD:refs/remotes/origin/HEAD'` (never executed)
#0 2.291
#0 2.291 Caused by:
#0 2.292   No such file or directory (os error 2)
------
WARNING: No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
Dockerfile:22
--------------------
  20 |     # This is a dummy build to get the dependencies cached.
  21 |     #
  22 | >>> RUN cargo build --config net.git-fetch-with-cli=true --target x86_64-unknown-linux-musl --release
  23 |
  24 |     # Now copy in the rest of the sources
--------------------
error: failed to solve: process "/bin/sh -c cargo build --config net.git-fetch-with-cli=true --target x86_64-unknown-linux-musl --release" did not complete successfully: exit code: 101

For instance, I'm using the base docker image rustlang/rust:nightly-buster-slim, and it does NOT have git

$ docker run -ti rustlang/rust:nightly-buster-slim git --version
Unable to find image 'rustlang/rust:nightly-buster-slim' locally
nightly-buster-slim: Pulling from rustlang/rust
ebcd4e3db076: Pull complete
c63476507cda: Pull complete
Digest: sha256:609c65daad3c69f9a37717e45d794e2eab99ad488dc5d492b8fc85c97c1df531
Status: Downloaded newer image for rustlang/rust:nightly-buster-slim
docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "git": executable file not found in $PATH: unknown.
ERRO[0044] error waiting for container: context canceled

Fix in this case

Just make sure to have git installed before

RUN apt-get update && apt-get install -y git
RUN cargo build --config net.git-fetch-with-cli=true --target x86_64-unknown-linux-musl --release


About the resolution (FFHQ)

Hi,
Thanks for  your nice work!!
I have a question. Can the pretrained model for 1024x1024 FFHQ image generation be directly used for 256x256 ?
Best.

No, although skip connection is used, color ranges and shapes will be different.

Got that. Thanks for your kind reply!

No, although skip connection is used, color ranges and shapes will be different.

Recently, I wanna use the pretrained model for 1024x1024 FFHQ image generation to train my own datasets , which is 512x512.
What should i do?

@freedom521jin You can remove layers for 1024px in pretrained model, or you can try to add 1/2x and 2x resample layers in the generator and discriminator.


Create a demo for the docker registry generic connector

Is your feature request related to a problem? Please describe.
There is no demo for the docker registry generic connector.
Describe the solution you would like
Create a demonstration of the docker registry generic connector in action. The goal is to have the demo flow around a Jenkins server hosted in Kubernetes that authenticates with Secretless to push and pull from a private Docker Registry.
Describe alternatives you have considered
Additional context
This stems from this Epic to create more generic connector examples.

Notes
After a lot of trial and error, I decided to drop the Kubernetes part of this tutorial. It was over complicating it and creating tons of problems. I decided to pivot to a docker-compose file to stand up the environment.
The initial workflow of using the generic connector to authenticate for push/pulling images to/from a Docker Registry does not seem like a practical example of maintaining images in a Jenkins pipeline. I'm looking into other possible ways of using Secretless to authenticate with Docker to make the tutorial

@JakeQuilty can you share more details about what you're looking into? If I connect to a remote Docker registry now, I unfailingly use the CLI (I never make direct API calls) - is there a way to configure the CLI to connect to Secretless as if it's the remote registry, and have Secretless add the correct headers to the requests Secretless sends? Is that doable with the generic connector, or would a more flexible custom connector be needed for this use case? The more details you can add, the better we'll be able to understand how to push this forward.

Update
After a lot of playing with the CLI, I'm not sure if this is practical with the way the CLI authenticates the user on docker login.
The CLI requires a user to be "logged in" before making a docker push or docker pull command through the CLI. The CLI stores the "logged in" registry in ~/.docker/config.json and stores the users username and password in the specified credential store in the same ~/.docker/config.json under "credsStore": (the default for OS X is desktop which is the OS X Keychain). If you delete the credsStore parameter, it will store the credentials unencrypted as a parameter in the specific registry you logged into as a base64 formatted "auth": "username:password".
The Docker CLI feeds these credentials straight the way they are to the Docker Daemon. The Docker Daemon then "logs in" to the Registry by, from everything I've seen, sending the credentials to the Registry and receiving a Bearer Token on every CLI request that goes out to the Registry. This article was really helpful for describing how the CLI authenticates. The MiTM the author uses makes Secretless seem possible between the Daemon and the Registry. I have not been able to set up a proxy for the Daemon on OS X and this thread confirmed it wasn't possible(after hours of trying).
I haven't been able to test this on a Linux VM yet, because I ran out of time for the day.
Regardless if Secretless can be hacked into a proxy between the Docker Daemon and the Registry, I think the set up required to do this might kill the ability to scale it through Jenkins servers in containers. The only way I was able to trick the CLI into allowing a CLI command that required authentication to go through to the Daemon was by deleting the default credsStore and adding the registry address manually to the config.json.
Credential Helpers
After looking at this for a while, I think a good way to achieve the same goal of keeping the Docker credentials off of the Jenkins server would be to use Conjur as a Docker credential help. This does not seem too difficult to implement and would keep the credentials off the Jenkins server until they are used. These are just binaries that are called to store, get, erase, and list the credentials for each Registry. On OS X these are stored in /Applications/Docker.app/Contents/Resources/bin.

Update
I don’t think this is possible without making a specific connector for HTTP. In an Ubuntu vm I was able to put a Secretless proxy between the daemon and the registry. I used this blog about Docker Authentication again and this Docker doc to set it up.
$ cat /etc/systemd/system/docker.service.d/http-conf.conf
[Service]
Environment=“HTTP_PROXY=http://localhost:8021”
Environment=“HTTPS_PROXY=https://localhost:8021”

I used the generic HTTP config for Docker Registries. Unfortunately, when trying to docker login or docker pull(commands that require auth with the registry) I got this error:
$ docker pull jacobquilty/test-private
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: tls: first record does not look like a TLS handshake

I don’t think generic HTTP connectors will work OOB with the Docker CLI, because of how the daemon authenticates with the Registry.
Suggested Solution
We should make a specific connector for Docker CLI. There are two places to put Secretless to authenticate with the Docker CLI.
Docker CLI --> Secretless -->  Docker Daemon
The Docker daemon default listens on this sock: unix:///var/run/docker.sock that the CLI sends its commands to. This can be changed by following BIND DOCKER TO ANOTHER HOST/PORT OR A UNIX SOCKET(scroll down, there was no anchor on that part). Here we could inject the username and password for the Registry user. The format for these creds is mentioned in my first comment. I’m not too familiar with socks, so I’m not sure how practical this is for remote Secretless servers, but it’s an option.
Docker Daemon --> Secretless --> Docker Registry
For this we’d use an HTTP connector to inject the Bearer token into the request to the Registry. We’d have to work around credential handshake that the Daemon and Registry do to get the API token. I spent most of my time looking at this, so most of my notes give more details about this.

Putting this on hold until there is a Docker CLI connector. I created a new issue to create the connector here: https://github.com/cyberark/secretless-broker/issues/1312


Clarify the PolicyHub integration for consumer applications

Description
There needs to be clarified with the responsible parties from the Policy Hub if there is required a integration with the digital product pass consumer application with the PolicyHub.
Basically we consume data from the network and get the contract details with the policies. As I understand the consumer would be able to support also not "Catena-X" policies. Therefore no limitation for schema is applied. The question is:

What is the real influence from the PolicyHub in the Digital Product Pass Consumer Application?

Acceptance Criteria

[ ] Clarify the policy hub integration
[ ] In case it is required implement the functionality.

Hi @jjeroch!
If you would be so kind can you clarify this for us?
Thank you very much :)

Clarified with @jjeroch. The policy hub is optional to be integrated. It gives a guideline on how to create the policies and helps you to check  the schemas.


Icon for .proto files (Google Protocol Buffer)

Would be nice to have an icon for Google Protocol buffer files which have the .proto extension

is there any icon?

That's a good question and after having a quick search around I can't find one.

Do you have a idea how the icon can look like?

+1, I also would love to have a *.proto icon
idea for icon:
Could be derived from JSON icon, but using a different color for the braces.
In my brain, this wakes the "struct" association in my brain, which protobuf is all about.
It is about declaring structs.

Found this logo

Using vscode 1.10.2 on Windows with vsicons 7.5.1 and viewing either .proto || .proto3 i'm not seeing the icon. Can someone verify it works on there system?

Install any of https://marketplace.visualstudio.com/search?term=protobuf&target=VSCode&category=All categories&sortBy=Relevance

Sorry, didn't realize that was a requirement, fixed!


Reduce number of closures generated when using GlobalGenerator

When using GlobalGenerator rustc currently generates a lot of duplicate code for the closures in gl::load_with.
This PR changes the generator, so that instead of generating a new closure for every {cmd_name}::load_with call, the loadfn closure is borrowed.
Looking at a macOS release build of gl/examples/basic.rs, the binary size is reduced from 983 KiB to 675 KiB. Compile time is also improved. The translation pass goes from 0.560 secs to 0.222 secs and the LLVM passes go from 5.923 secs to 4.265 secs.

Wondering if any of the other generators need to be updated as well 🤔

Awesome work by the way, and thanks for the timings! ❤

Looking through, it seems to be ok. I'll merge this and publish an update!


Ordered Consumer

Overview
Implement Ordered Consumer as documented in https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-17.md
Clients and Tools

[x] Go @wallyqs
[x] Java @scottf
[x] JavaScript @aricart
[x] .Net @ColinSullivan1 @scottf
[x] C @kozlovic
[x] Python @wallyqs
[x] Rust @Jarema

Other Tasks

[x] docs.nats.io updated
[ ] Update ADR to Implemented
[x] Update client features spreadsheet

Client authors please update with your progress. If you open issues in your own repositories as a result of this request, please link them to this one by pasting the issue URL in a comment or main issue description.

Anything left to do other than update the ADR doc?


Ensure that copied files are writeable

I tried to run the HelloWorld example from within Julia, using the Birch_jll package, and noticed that birch init --package HelloWorld fails (https://github.com/JuliaPackaging/Yggdrasil/issues/1969#issuecomment-737306907). The problem is that the Julia package manager enforces the immutability of the installed binaries by making all files read-only (https://github.com/JuliaLang/Pkg.jl/blob/cce236e1866f6fe2653a4e202bc6eca47f8ddd7a/src/Artifacts.jl#L60), and these read-only file permissions are then propagated to the files that are copied to the user directory. When Birch tries to modify birch.yml this leads to an error.
It was suggested in the linked issue to copy the files manually in Julia but I was not satisfied with this solution since it seems weird to reimplement an existing feature of Birch and it would have to be updated whenever birch init or the distributed files are changed. Instead I thought it would be easier to handle this issue in Birch and ensure that the copied files are writeable by the user. If you do not want to include this functionality in Birch, I could just add it as a patch to the Julia build script.
I checked the PR locally by manually modifying the permissions of the installed files in the ${PREFIX}/share/birch/ directory and running birch init --package HelloWorld. It was not clear to me if such a test should be included in CircleCI or Cirrus to avoid any regressions.

Thanks again @devmotion. Agree this is better to have in Birch itself rather than handling with Julia. It may affect other package managers as well, and isn't harming anything else after all, it's just being more explicit with setting permissions. No great need for CI tests here I think, unlikely to regress accidentally given the way you've implemented it. Nice to have, thanks!


[feature request] Howdy multi-factor authentication

During installation and later through the config, user should be able to decide whether they want to replace current password with face recognition or keep the password and use Howdy as another security layer. In case of failure, the user should be prompted to enter second password given during configuration.

One of the wiki pages explains parts of how to change PAM.
The goal of Howdy is to speed up logging in wile not lowering security too much. This is why Howdy is sufficient in PAM by default, and why there is no configuration option. However, maybe it would be nice to have a dedicated wiki page explaining how to configure Howdy for the other setups you mentioned


TN-177: activate links for exercise and diet and lived experience pages on GIL

address story TN-177:  https://jira.movember.com/browse/TN-177

activate links for exercise and diet and lived experience pages on GIL about page

Hmm, steps on the blueprint work in process.  Can we hold off on this merge?

@pbugni Oh k, I am closing this for now.  Will re-open when the blueprint changes are ready.


UISegmentedControl support?

Hi! Awesome work.
Is there support for UISegmentedControl? I tried the following:
<UISegmentedControl
    items="['A', 'B']"
    children="['A', 'B']"
    width="100%"
    top="previous.bottom + 10">
</UISegmentedControl>

Clearly I have a fundamental misunderstanding of how the element is supposed to work. It doesn't throw an error for the overall element, but does for both items & children properties.
I tried nesting elements within the control - also to no avail.
Is there some documentation that I missed that lists properties on a per element basis?
Thanks in advance for any help you can lend.

@nextriot UISegmentedControl is not really supported yet. You might be able to make it work by passing items in as a constant or state variable from native Swift code, but there's currently no way to specify array literals using expressions in XML.

@nicklockwood thanks for the speedy reply!
So given that I now have access to the constant in the xml, how would I then pass this as an attribute to the controller given that items is still seen as an unknown property? I went through the section on constants, but I'm not seeing a clear-cut way that specifies that.
self.loadLayout(
    named: "Label.xml",
    constants: [
        "items": ["A", "B"]
    ]
)

<UISegmentedControl
    width="100%"
    top="previous.bottom + 10"
    items="{items}"
/>

@nextriot sorry, I should have checked the UISegmentedControl API more carefully - it seems that items isn't a real property, it's just a constructor argument for init, which isn't available in Layout without a custom extension.
The only way you can do it for now is to create an outlet for the UISegmentedControl and then set the items programmatically. Something like this:
<UISegmentedControl
    outlet="segmentedControl"
    width="100%"
    top="previous.bottom + 10"
/>

Then in your view controller:
@IBOutlet weak var segmentedControl: UISegmentedControl? {
    didSet {
        segmentedControl?.insertSegment(withTitle: "A", at segment: 0, animated: false)
        segmentedControl?.insertSegment(withTitle: "B", at segment: 1, animated: false)
    }
}

Or alternatively:
@IBOutlet weak var segmentedControl: UISegmentedControl?

override open func layoutDidLoad() {
     segmentedControl?.insertSegment(withTitle: "A", at segment: 0, animated: false)
     segmentedControl?.insertSegment(withTitle: "B", at segment: 1, animated: false)
}

I know that's not very satisfactory. I'll try to add proper support for UISegmentedControl in the next release.

That's brilliant! Thanks again @nicklockwood. Looking forward to it.

OK, I've added improved support for UISegmentedControl in 0.4.18. This should now work:
self.loadLayout(
    named: "Label.xml",
    constants: [
        "items": ["A", "B"]
    ]
)

<UISegmentedControl
    width="100%"
    top="previous.bottom + 10"
    items="{items}"
/>


[simdjson] Update to 3.1.5

[x] Changes comply with the maintainer guide
[x] SHA512s are updated for each updated download
[ ] The "supports" clause reflects platforms that may be fixed by this new version
[ ] Any fixed CI baseline entries are removed from that file.
[ ] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

I checked that the latest version of simdjson is 3.1.5, please update to the latest version.

Thanks. @jimwang118 It seems simdjson has two new releases in the past 24 hours.

All feature passed with following triplets:
x86-windows
x64-windows
x64-windows-static


FFI section suggests dangerous practice of using empty opaque type

The FFI section of the Nomicon currently suggests to use an empty type for "opaque pointer types". That seems pretty dangerous. This came up in the discussion at https://github.com/rust-lang/rfcs/pull/1861, and also in https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602 many were not happy with using the empty type here.
Until we have proper opaque types, the safer suggestion seems to be do use a ZST with a private field, rather than an empty type. Then at least the type is not actively lying.

How is this dangerous?

with x: &Empty, match *x {} could well be (no final decision has been bade yet) insta-UB if ever executed.
Actually, just passing a &Empty to another function is not really different from passing aliasing &mut u32 to functions like mem::swap -- the promise made by the type is violated. It is not unlikely for the unsafe code guidelines process to decide that doing either of these is UB.

&Empty is not okay, but you're working with *mut Empty and *const Empty in FFI.

&Empty is not okay,

Glad we agree on that. :)

you're working with *mut Empty and *const Empty in FFI.

While these types are fine, I am worried that people will quickly move to variables or function arguments of type &Empty in the wrappers they build around their FFI code.
This happened e.g. in https://github.com/briansmith/ring/, where BIGNUM used to be an empty enum, and you can indeed find &BIGNUM in the code.

I’ve opened https://github.com/rust-lang-nursery/nomicon/pull/44 to recommend zero-size structs with a private field, instead.
https://github.com/rust-lang/rust/pull/45225#issuecomment-346493804 is another case of Bad Things happening with empty enums used in types that are not "impossible".


What frameworks do you want?

Angular w/ typescript

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

ID: 0ba3dbcc-00b5-1896-969e-71cd4385a7a3
Version Independent ID: deaea059-3262-cc12-f45a-3346083d4b6a
Content: Adaptive Cards for Bot Developers - Adaptive Cards
Content Source: AdaptiveCards/resources/Future.md
Service: unspecified
GitHub Login: @matthidinger
Microsoft Alias: mahiding

We really need React and React-Native to be available soon, because within the product I'm working on, that would match the technology stack of our first and most important host. We would be willing to put work on it too, just let us know.

@ignacionr see these ongoing works:

https://github.com/tuanh118/AdaptiveCardsReactNative
https://www.npmjs.com/package/react-adaptivecards

I haven’t personally tried them

Angular please!
Thanks

Xamarin support for rendering was previously "planned". Please include it into the backlog. Thank you.

I need Xamarin bindings for Android and iOS. In Februari 2019 I asked about this and was told in March. Now in April, latest Xamarin related commit was 6 months ago, most are 2 years old. Is there any commitment for Xamarin support?


backup_nhg_test.go : Test FAILS due to static AFT entry not being installed because of missing valid backupNhg

Hi, While trying to run this test, we are experiencing the entire test is failing.
<<<OUTPUT OMITTED FOR BREVITY>>>
=== RUN   TestDirectBackupNexthopGroup/Disable_ATE_port-2
=== RUN   TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Baseline_AFT_Telemetry
    backup_nhg_test.go:416: No value present at path /network-instances/network-instance[name=default]/afts/ipv4-unicast/ipv4-entry[prefix=<IP_ADDRESS>/24]/state/next-hop-group
<<<OUTPUT OMITTED FOR BREVITY>>>
    backup_nhg_test.go:416: No value present at path /network-instances/network-instance[name=default]/afts/ipv4-unicast/ipv4-entry[prefix=<IP_ADDRESS>/24]/state/next-hop-group
<<<OUTPUT OMITTED FOR BREVITY>>>
--- FAIL: TestDirectBackupNexthopGroup (492.59s)
    --- FAIL: TestDirectBackupNexthopGroup/Disable_ATE_port-2 (193.92s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Baseline_AFT_Telemetry (0.23s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Baseline_Traffic_Delivery (90.55s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Backup_Path_Traffic_Delivery (95.72s)
    --- FAIL: TestDirectBackupNexthopGroup/Disable_DUT_port-2 (189.71s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_DUT_port-2/Validate_Baseline_AFT_Telemetry (0.28s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_DUT_port-2/Validate_Baseline_Traffic_Delivery (89.03s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_DUT_port-2/Validate_Backup_Path_Traffic_Delivery (90.78s)
--- FAIL: TestIndirectBackupNexthopGroup (277.95s)
    --- FAIL: TestIndirectBackupNexthopGroup/Validate_Baseline_Traffic_Delivery (85.12s)
    --- FAIL: TestIndirectBackupNexthopGroup/Validate_Backup_Path_Traffic_Delivery (89.27s)
FAIL

*** Releasing the testbed...

FAIL    command-line-arguments  812.322s
FAIL

As you see above the Telemetry is failing. In fact we are not able to install the AFT on our device.
Device logs
I0617 06:23:14.194973   29403 election_id.go:84] Client:6 is the new primary, electionId:High:0, Low:1
E0617 06:23:14.496811   29403 nhg_aft.go:187] fail: Missing valid backupNhg 102 in NHG Aft ID: 101
E0617 06:23:14.496923   29403 server.go:546] clientID:6 failed AFT operation: id:7 network_instance:"default" op:ADD next_hop_group:{id:101 next_hop_group:{backup_next_hop_group:{value:102} next_hop:{index:10000 next_hop:{weight:{value:1}}}}} election_id:{low:1}
E0617 06:23:14.496952   29403 ipv4_aft.go:101] fail: Unknown nhgId 101, prefix:<IP_ADDRESS>/24, vrf:default
E0617 06:23:14.496999   29403 server.go:546] clientID:6 failed AFT operation: id:8 network_instance:"default" op:ADD ipv4:{prefix:"<IP_ADDRESS>/24" ipv4_entry:{next_hop_group:{value:101}}} election_id:{low:1}

After some debug it seems there is issue in installing AFT because of backup NHG.
If we remove the WithBackupNHG() call as below, we are seeing some sub-tests in this test pass. Can someone suggest if in the code we need to first just simply define the NHGs before using the WithBackupNHG() call?
inside configureIndirBackupNHG function:
// nhg := fluent.NextHopGroupEntry().WithNetworkInstance(defaultNetworkInstance).                      <--- old code
        //         WithID(dstNHGID).AddNextHop(recurNHID, 1).WithBackupNHG(dstBackupNHGID)       <--- old code
        nhg := fluent.NextHopGroupEntry().WithNetworkInstance(defaultNetworkInstance).
                WithID(dstNHGID).AddNextHop(recurNHID, 1)

inside configureBackupNHG func:
        // nhg := fluent.NextHopGroupEntry().WithNetworkInstance(defaultNetworkInstance).              <--- old code
        //         WithID(dstNHGID).AddNextHop(dutPort2ID, 1).WithBackupNHG(dstBackupNHGID)       <--- old code
        nhg := fluent.NextHopGroupEntry().WithNetworkInstance(defaultNetworkInstance).
                WithID(dstNHGID).AddNextHop(dutPort2ID, 1)

Test Output post code change
--- FAIL: TestDirectBackupNexthopGroup (674.32s)
    --- FAIL: TestDirectBackupNexthopGroup/Disable_ATE_port-2 (185.21s)
        --- PASS: TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Baseline_AFT_Telemetry (0.85s)
        --- PASS: TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Baseline_Traffic_Delivery (88.17s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_ATE_port-2/Validate_Backup_Path_Traffic_Delivery (88.69s)
    --- FAIL: TestDirectBackupNexthopGroup/Disable_DUT_port-2 (195.44s)
        --- PASS: TestDirectBackupNexthopGroup/Disable_DUT_port-2/Validate_Baseline_AFT_Telemetry (0.78s)
        --- PASS: TestDirectBackupNexthopGroup/Disable_DUT_port-2/Validate_Baseline_Traffic_Delivery (95.60s)
        --- FAIL: TestDirectBackupNexthopGroup/Disable_DUT_port-2/Validate_Backup_Path_Traffic_Delivery (89.45s)

--- FAIL: TestIndirectBackupNexthopGroup (277.74s)
    --- PASS: TestIndirectBackupNexthopGroup/Validate_Baseline_Traffic_Delivery (85.15s)
    --- FAIL: TestIndirectBackupNexthopGroup/Validate_Backup_Path_Traffic_Delivery (89.53s)
FAIL

Hi,
I'm not sure if I am following.  The intent of this test is to evaluate the backup next-hop-group behavior.  If we remove the backup next hop group configuration, wouldn't that fundamentally change the test?
The key error seems to be in this message you quoted:
E0617 06:23:14.496811   29403 nhg_aft.go:187] fail: Missing valid backupNhg 102 in NHG Aft ID: 101
	nhg := fluent.NextHopGroupEntry().WithNetworkInstance(defaultNetworkInstance).
		WithID(dstNHGID).AddNextHop(dutPort2ID, 1).WithBackupNHG(dstBackupNHGID)
	bnhg := fluent.NextHopGroupEntry().WithNetworkInstance(defaultNetworkInstance).
		WithID(dstBackupNHGID).AddNextHop(dutPort3ID, 1)
...
		a.gribic.Modify().AddEntry(t, nh1, nh2, bnhg, nhg, pfx)

The entry bnhg has the id 102.  It gets installed first before the nhg entry.  For some reason the log message is indicating that it is not valid to be used as a backup next hop group, but I am not sure why.

Hi,
Thanks. Yes, I understand the point of the test. It was just a remark that without specifying the WithBackupNHG() things were working so the issue is here.
Can you tell me in which part of the code we are installing this backup NHG? You mentioned before adding 101, 102 is installed. In the code in previous comment nhg is defined before bnhg. Is this happening here or somewhere else in the code?
Then I would investigate this further in my device if we are having an error with this 102 installation for some reason.

They should be created in the order as listed on this line.  The backup next hop is specified first on that line.
I did try several variations such as having delays between the "bnhg" and "nhg" creations and I was running into the same issue/error you are seeing.  "bnhg" would appear to be valid but not when it was specified for use as a backup.

Thanks for the clarification. I will investigate this internally.


[Automation] Generate Fluent Lite from help#package-2023-01-01-preview

[Automation] Generate Fluent Lite from help#package-2023-01-01-preview
Release request: https://github.com/Azure/sdk-release-request/issues/4035
Archboard review: https://github.com/Azure/azure-sdk/issues/5817

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-selfhelp


Protect from bad (non-importable) repo names, like those with dashes

OK, the README does say "repo_name must be a valid Python module name or you will have issues on imports".  But let's be kind to bad README readers (ahem, me) and bake in some insulation - especially since dashes are so common in project names.  Otherwise hitch produces this very confusing error:
Command '['/home/catherine/.hitchpkg/postgresql-9.5.0/postgresql-9.5.0/bin/psql', '-d', 'template1', '-p', '15432', '--host', '/home/catherine/v/shared/rideshare-matchmaker/tests/.hitch/pgdata', '-c', "create user rideshare-matchmaker with password 'password';"]' returned non-zero exit status 1

+1 I like this idea. This hit me once before too.

Thanks @catherinedevlin for the pull-request. This is definitely a nice addition.

I love this pull request. I'm going to add it to a number of my other Cookiecutter templates. :smile: