Inspector no longer opens a Shader inline.

Godot version
v3.5.rc4.official [e047c5006]
System information
Windows 10, Intel Graphics, GLES3
Issue description
When editing a Shader resource in a ShaderMaterial, the inspector used to stay on the ShaderMaterial with Shader in an inline panel, and shader text in the bottom editor.

Now Shader takes over the whole inspector, and going back to ShaderMaterial closes the bottom shader text panel.

Working on a shader program and tweaking the uniforms now requires constantly jumping back and forth, because you can never see ShaderMaterial's shader params and Shader's text at the same time.
Steps to reproduce
Create and edit a ShaderMaterial.
Minimal reproduction project
No response

Likely a regression from https://github.com/godotengine/godot/pull/61459.

Likely a regression from #61459.

I don't think #61459 was backported to 3.5, was it?

@icecoldtofu Could you specify the last Godot version where the shader editor behaved as you expected?

Looks to be the same issue as https://github.com/godotengine/godot/issues/60640, which was created by https://github.com/godotengine/godot/pull/60500 and fixed by https://github.com/godotengine/godot/pull/60642

@Calinou The last version I found where it works the way it should is v3.3.4.stable.official [faf3f883d].
And v3.4.stable.official [206ba70f4] is the first where Shader is no longer nested.

This is somewhat intended, see #52984
However I noticed that sometimes resources that are supposed to nest (e.g. ParticlesMaterial and ShaderMaterial), don't. But I can't reproduce it now 🤔

Using v3.4.beta5.official [dd0ee48] I just put an AtlasTexture in a shader uniform (just to have a nested resource inside a nested resource where both have their own contextual editors) and the inspector has no problem switching between the shader editor for the Shader and the region editor for the AtlasTexture.
Maybe since Shader doesn't seem to be one of the troublesome resources it could be excluded from that temporary fix in the interest of usability.


Deprecate ihaskell-display

Hackage has an ihaskell-display package with a dependency on base == 4.6.* I assume it's not actively developed, and that module now lives in ihaskell? If so, would you mind marking ihaskell-display deprecated on hackage?

Sure, it's been deprecated in favour of ihaskell.


Support for LDS ZBT-CCTSwitch-D0001

This is a 4 button remote that came from an EcoSmart Kit sold by Home Depot. It pairs with ZHA and presents its battery level, but produces nothing in the log when buttons are pressed. I have little experience with Zigbee, so I'm not sure where to go from here.
FCC ID is 2AB2Q6ARCZABZH if that helps.

Quirk Stub
"""Device handler for LDS ZBT-CCTSwitch-D001."""
from zigpy.profiles import zha
from zigpy.quirks import CustomDevice
from zigpy.zcl.clusters.general import (
    Basic,
    Groups,
    PowerConfiguration,
    Identify,
    LevelControl,
    Ota,
    OnOff,
)
from zigpy.zcl.clusters.lighting import Color
from zigpy.zcl.clusters.lightlink import LightLink

from ..const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
 )

MANUFACTURER_SPECIFIC_CLUSTER_ID_1 = 0xFD01  # decimal = 64769

class LDSZBTCCTSwitch(CustomDevice):
    """Custom device representing LDS ZBT-CCTSwitch-D001."""

    signature = {
        #  <SimpleDescriptor endpoint=1 profile=260 device_type=2048
        #  device_version=1
        #  input_clusters=[0, 1, 3, 4096, 64769]
        #  output_clusters=[3, 4, 6, 8, 25, 768, 4096]>
        MODELS_INFO: [("LDS", "ZBT-CCTSwitch-D0001")],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.COLOR_CONTROLLER,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    Identify.cluster_id,
                    LightLink.cluster_id,
                    MANUFACTURER_SPECIFIC_CLUSTER_ID_1,
                ],
                OUTPUT_CLUSTERS: [
                    Identify.cluster_id,
                    Groups.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    Ota.cluster_id,
                    Color.cluster_id,
                    LightLink.cluster_id,
                ],
            }
        },
    }

    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.COLOR_CONTROLLER,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    PowerConfiguration.cluster_id,
                    Identify.cluster_id,
                    LightLink.cluster_id,
                    MANUFACTURER_SPECIFIC_CLUSTER_ID_1,
                ],
                OUTPUT_CLUSTERS: [
                    Identify.cluster_id,
                    Groups.cluster_id,
                    OnOff.cluster_id,
                    LevelControl.cluster_id,
                    Ota.cluster_id,
                    Color.cluster_id,
                    LightLink.cluster_id,
                ],
            }
        },
    }

Pairing Log
2019-12-05 19:04:50 INFO (MainThread) [zigpy.application] Device 0xf154 (cc:cc:cc:ff:fe:c6:d1:7a) joined the network
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.application] Device cc:cc:cc:ff:fe:c6:d1:7a changed id (0x7bb3 => 0xf154)
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.device] Canceling old initialize call
2019-12-05 19:04:50 INFO (MainThread) [zigpy.device] [0xf154] Requesting 'Node Descriptor'
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x09 request
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'040000060000000800000070ffc454f1ffff0901fdff040101190000'
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.zdo] [0xf154:zdo] ZDO request 0x0006: [0xfffd, 260, [25], []]
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 98 (incomingSenderEui64Handler) received: b'7ad1c6feffcccccc'
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=32774 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=1>, 11, b'\x01\x00\x00\x00\x01\x01')
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'040000130000000804000071ffc454f1ffff0c8154f17ad1c6feffcccccc80'
2019-12-05 19:04:50 INFO (MainThread) [zigpy.application] Device 0xf154 (cc:cc:cc:ff:fe:c6:d1:7a) joined the network
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.application] Skip initialization for existing device cc:cc:cc:ff:fe:c6:d1:7a
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.zdo] [0xf154:zdo] ZDO request 0x0013: [0xf154, cc:cc:cc:ff:fe:c6:d1:7a, 128]
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'006f'
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=2 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=9>, 10, b'\tT\xf1')
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0070'
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1000006800000400100006f0b0000'
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000028000004001000072ffc654f1ffff11090054f10240806811525200002c520000'
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f100000200000040010000700a0000'
2019-12-05 19:04:50 INFO (MainThread) [zigpy.device] [0xf154] Node Descriptor: <Optional byte1=2 byte2=64 mac_capability_flags=128 manufacturer_code=4456 maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264 maximum_outgoing_transfer_size=82 descriptor_capability_field=0>
2019-12-05 19:04:50 INFO (MainThread) [zigpy.device] [0xf154] Discovering endpoints
2019-12-05 19:04:50 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x0c request
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=5 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=12>, 13, b'\x0cT\xf1')
2019-12-05 19:04:50 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0071'
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000058000004001000073ffc554f1ffff060c0054f10101'
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f100000500000040010000710d0000'
2019-12-05 19:04:51 INFO (MainThread) [zigpy.device] [0xf154] Discovered endpoints: [1]
2019-12-05 19:04:51 INFO (MainThread) [zigpy.endpoint] [0xf154:1] Discovering endpoint information
2019-12-05 19:04:51 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x0e request
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=4 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=14>, 15, b'\x0eT\xf1\x01')
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0072'
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000048000004001000074ffc754f1ffff250e0054f12001040100080105000001000300001001fd070300040006000800190000030010'
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f100000400000040010000720f0000'
2019-12-05 19:04:51 INFO (MainThread) [zigpy.endpoint] [0xf154:1] Discovered endpoint information: <SimpleDescriptor endpoint=1 profile=260 device_type=2048 device_version=1 input_clusters=[0, 1, 3, 4096, 64769] output_clusters=[3, 4, 6, 8, 25, 768, 4096]>
2019-12-05 19:04:51 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x10 request
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=0 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=16>, 17, b'\x00\x10\x00\x04\x00\x05\x00')
2019-12-05 19:04:51 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0073'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401000001014000000075ffc754f1ffff2318100104000042034c445305000042135a42542d4343545377697463682d4430303031'
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=16 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10401000001014001000073110000'
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.endpoint] [0xf154:1] Manufacturer: LDS
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.endpoint] [0xf154:1] Model: ZBT-CCTSwitch-D0001
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Checking quirks for LDS ZBT-CCTSwitch-D0001 (cc:cc:cc:ff:fe:c6:d1:7a)
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zigpy.quirks.smartthings.SmartthingsMultiPurposeSensor'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because device_type mismatch on at least one endpoint
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'bellows.zigbee.application.EZSPCoordinator'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because device_type mismatch on at least one endpoint
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.gledopto.soposhgu10.SoposhGU10'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because endpoint list mismatch: {11, 13} {1}
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.lutron.lzl4bwhl01remote.LutronLZL4BWHL01Remote2'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because profile_id mismatch on at least one endpoint
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.netvox.z308e3ed.Z308E3ED'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because device_type mismatch on at least one endpoint
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.osram.a19twhite.A19TunableWhite'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because endpoint list mismatch: {3} {1}
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.philips.rwl021.PhilipsRWL021'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because endpoint list mismatch: {1, 2} {1}
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.smartthings.tag_v4.SmartThingsTagV4'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because device_type mismatch on at least one endpoint
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.xbee.xbee3_io.XBee3Sensor'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because endpoint list mismatch: {232, 230} {1}
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.xbee.xbee_io.XbeeSensor'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because endpoint list mismatch: {232, 230} {1}
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.xiaomi.mija.smoke.MijiaHoneywellSmokeDetectorSensor'>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.quirks.registry] Fail because device_type mismatch on at least one endpoint
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00040100030101400100008dffbf6fa0ffff1208410a0300217a540400217a540700217201'
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xa06f:1:0x0300] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=65 command_id=Command.Report_Attributes>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xa06f:1:0x0300] ZCL request 0x000a: [[<Attribute attrid=3 value=<TypeValue type=uint16_t, value=21626>>, <Attribute attrid=4 value=<TypeValue type=uint16_t, value=21626>>, <Attribute attrid=7 value=<TypeValue type=uint16_t, value=370>>]]
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xa06f:1:0x0300] Attribute report received: current_x=21626, current_y=21626, color_temperature=370
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event device_registry_updated[L]: action=create, device_id=8f54115b95f547bea551c1426993a4bf>
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.gateway] device - 0xf154:cc:cc:cc:ff:fe:c6:d1:7a entering async_device_initialized - is_new_join: True
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.gateway] device - 0xf154:cc:cc:cc:ff:fe:c6:d1:7a has joined the ZHA zigbee network
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xf154](ZBT-CCTSwitch-D0001): started configuration
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:ZDO](ZBT-CCTSwitch-D0001): channel: 'async_configure' stage succeeded
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x12 request
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x14 request
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x16 request
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=18>, 19, b'\x12z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x00\x00\x03\x1fN=\x0b\x00o\r\x00\x01')
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=20>, 21, b'\x14z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x01\x00\x03\x1fN=\x0b\x00o\r\x00\x01')
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=22>, 23, b'\x16z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x00\x10\x03\x1fN=\x0b\x00o\r\x00\x01')
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0074'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0075'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0076'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401190001014000000076ffc754f1ffff0e0100010168110f03060000210100'
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0019] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=0 command_id=1>
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0019] ZCL request 0x0001: [1, 4456, 783, 553648134, 1]
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000218000004001000077ffc754f1ffff021200'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10000210000004001000074130000'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000218000004001000078ffc754f1ffff021400'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10000210000004001000075150000'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000218000004001000079ffc754f1ffff021600'
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0019] OTA query_next_image handler for 'LDS ZBT-CCTSwitch-D0001': field_control=1, manufacture_id=4456, image_type=783, current_file_version=553648134, hardware_version=1
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10000210000004001000076170000'
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0019] No OTA image is available
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=25 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=0>, 24, b'\x19\x00\x02\x98')
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0000]: bound 'basic' cluster: Status.SUCCESS
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0000]: finished channel configuration
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x19 request
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: bound 'power' cluster: Status.SUCCESS
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x1b request
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x1000]: bound 'lightlink' cluster: Status.SUCCESS
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x1000]: finished channel configuration
2019-12-05 19:04:52 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x1000]: channel: 'async_configure' stage succeeded
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0077'
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:52 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x1d request
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=0 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=25>, 26, b'\x00\x19\x00\x07\x00')
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=1 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=27>, 28, b'\x00\x1b\x06\x00 \x00 \x10\x0e0*\x01')
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:52 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=29>, 30, b'\x1dz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x06\x00\x03\x1fN=\x0b\x00o\r\x00\x01')
2019-12-05 19:04:53 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0078'
2019-12-05 19:04:53 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0079'
2019-12-05 19:04:53 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'007a'
2019-12-05 19:04:53 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'04000036000000080000007affc754f1ffff0302b401'
2019-12-05 19:04:53 DEBUG (MainThread) [zigpy.zdo] [0xf154:zdo] ZDO request 0x0036: [180, <Bool.true: 1>]
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10401190001014001000077180000'
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00040100000101400000007bffc754f1ffff081819010700003003'
2019-12-05 19:04:54 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=25 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f104010000010140010000781a0000'
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00040101000101400000007cffc754f1ffff04081b0700'
2019-12-05 19:04:54 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=27 command_id=Command.Configure_Reporting_rsp>
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f104010100010140010000791c0000'
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00000021800000400100007dffc754f1ffff021d00'
2019-12-05 19:04:54 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1000021000000400100007a1e0000'
2019-12-05 19:04:54 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0000]: initializing channel: from_cache: False
2019-12-05 19:04:54 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0000]: channel: 'async_configure' stage succeeded
2019-12-05 19:04:54 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: reporting 'battery_voltage' attr on 'power' cluster: 3600/10800/1: Result: '[[<ConfigureReportingResponseRecord status=Status.SUCCESS>]]'
2019-12-05 19:04:54 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x1f request
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:55 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0006]: bound 'on_off' cluster: Status.SUCCESS
2019-12-05 19:04:55 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0006]: finished channel configuration
2019-12-05 19:04:55 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0006]: channel: 'async_configure' stage succeeded
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:55 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x21 request
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=31>, 32, b'\x1fz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x08\x00\x03\x1fN=\x0b\x00o\r\x00\x01')
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=33>, 34, b'!z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x00\x03\x03\x1fN=\x0b\x00o\r\x00\x01')
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'007b'
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'007c'
2019-12-05 19:04:55 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x23 request
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=1 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=35>, 36, b'\x00#\x06\x00!\x00 \x10\x0e0*\x01')
2019-12-05 19:04:55 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'007d'
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00000021800000400100007effc754f1ffff021f00'
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1000021000000400100007b200000'
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0008]: bound 'level' cluster: Status.SUCCESS
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0008]: finished channel configuration
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0008]: channel: 'async_configure' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00000021800000400100007fffc754f1ffff022100'
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1000021000000400100007c220000'
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401010001014000000080ffc754f1ffff0408230700'
2019-12-05 19:04:56 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=35 command_id=Command.Configure_Reporting_rsp>
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1040101000101400100007d240000'
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0300]: bound 'light_color' cluster: Status.SUCCESS
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0300]: finished channel configuration
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0300]: channel: 'async_configure' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: reporting 'battery_percentage_remaining' attr on 'power' cluster: 3600/10800/1: Result: '[[<ConfigureReportingResponseRecord status=Status.SUCCESS>]]'
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: finished channel configuration
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: channel: 'async_configure' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xf154](ZBT-CCTSwitch-D0001): completed configuration
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xf154](ZBT-CCTSwitch-D0001): stored in registry: ZhaDeviceEntry(name='LDS ZBT-CCTSwitch-D0001', ieee='cc:cc:cc:ff:fe:c6:d1:7a', last_seen=1575572696.4221933)
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xf154](ZBT-CCTSwitch-D0001): started initialization
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:ZDO](ZBT-CCTSwitch-D0001): entry loaded from storage: ZhaDeviceEntry(name='LDS ZBT-CCTSwitch-D0001', ieee='cc:cc:cc:ff:fe:c6:d1:7a', last_seen=1575572696.4221933)
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:ZDO](ZBT-CCTSwitch-D0001): channel: 'async_initialize' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x25 request
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:56 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x27 request
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x1000]: initializing channel: from_cache: False
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x1000]: channel: 'async_initialize' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0006]: initializing channel: from_cache: False
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0006]: channel: 'async_initialize' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0008]: initializing channel: from_cache: False
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0008]: channel: 'async_initialize' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0300]: initializing channel: from_cache: False
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0300]: channel: 'async_initialize' stage succeeded
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event device_registry_updated[L]: action=update, device_id=8f54115b95f547bea551c1426993a4bf>
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event entity_registry_updated[L]: action=create, entity_id=sensor.lds_zbt_cctswitch_d0001_7ad1c6fe_power>
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=0 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=37>, 38, b'\x00%\x00\x07\x00')
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=1 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=39>, 40, b"\x00'\x001\x00")
2019-12-05 19:04:56 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.lds_zbt_cctswitch_d0001_7ad1c6fe_power, old_state=None, new_state=<state sensor.lds_zbt_cctswitch_d0001_7ad1c6fe_power=91; unit_of_measurement=%, friendly_name=LDS ZBT-CCTSwitch-D0001 7ad1c6fe power, device_class=battery @ 2019-12-05T14:04:56.967247-05:00>>
2019-12-05 19:04:56 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'007e'
2019-12-05 19:04:57 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'007f'
2019-12-05 19:04:57 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401000001014000000081ffc754f1ffff081825010700003003'
2019-12-05 19:04:57 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=37 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:04:57 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1040100000101400100007e260000'
2019-12-05 19:04:57 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401010001014000000082ffc754f1ffff081827013100003002'
2019-12-05 19:04:57 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=39 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:04:57 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0000]: initializing channel: from_cache: False
2019-12-05 19:04:57 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0000]: channel: 'async_initialize' stage succeeded
2019-12-05 19:05:00 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'00b37b000002000000400000006d086600'
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401020402010001000094feaafb36ffff0808670a0000294c06'
2019-12-05 19:05:06 DEBUG (MainThread) [zigpy.zcl] [0x36fb:2:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=103 command_id=Command.Report_Attributes>
2019-12-05 19:05:06 DEBUG (MainThread) [zigpy.zcl] [0x36fb:2:0x0402] ZCL request 0x000a: [[<Attribute attrid=0 value=<TypeValue type=int16s, value=1612>>]]
2019-12-05 19:05:06 DEBUG (MainThread) [zigpy.zcl] [0x36fb:2:0x0402] Attribute report received: measured_value=1612
2019-12-05 19:05:06 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.back_porch_motion_detector_159e4606_temperature, old_state=<state sensor.back_porch_motion_detector_159e4606_temperature=16.0; unit_of_measurement=°C, friendly_name=Back Porch Motion Detector 159e4606 temperature, device_class=temperature @ 2019-12-05T13:56:57.654211-05:00>, new_state=<state sensor.back_porch_motion_detector_159e4606_temperature=16.1; unit_of_measurement=°C, friendly_name=Back Porch Motion Detector 159e4606 temperature, device_class=temperature @ 2019-12-05T14:05:06.349911-05:00>>
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401010001014000000083ffc754f1ffff081827013100003002'
2019-12-05 19:05:06 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=39 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:05:06 DEBUG (MainThread) [zigpy.device] [0xf154] Invalid state on future for 0x27 seq -- probably duplicate response
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f1040101000101400100007f280000'
2019-12-05 19:05:06 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x29 request
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=1 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=41>, 42, b'\x00)\x00!\x00')
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0080'
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:05:06 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401010001014000000084ffc754f1ffff081829012100002076'
2019-12-05 19:05:07 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=41 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f104010100010140010000802a0000'
2019-12-05 19:05:07 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x2b request
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:05:07 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=sensor.lds_zbt_cctswitch_d0001_7ad1c6fe_power, old_state=<state sensor.lds_zbt_cctswitch_d0001_7ad1c6fe_power=91; unit_of_measurement=%, friendly_name=LDS ZBT-CCTSwitch-D0001 7ad1c6fe power, device_class=battery @ 2019-12-05T14:04:56.967247-05:00>, new_state=<state sensor.lds_zbt_cctswitch_d0001_7ad1c6fe_power=59; unit_of_measurement=%, friendly_name=LDS ZBT-CCTSwitch-D0001 7ad1c6fe power, device_class=battery @ 2019-12-05T14:05:07.425104-05:00>>
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=1 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=43>, 44, b'\x00+\x00 \x00')
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0081'
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401010001014000000085ffc754f1ffff08182b01200000201d'
2019-12-05 19:05:07 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=43 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f104010100010140010000812c0000'
2019-12-05 19:05:07 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x2d request
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:05:07 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=260 clusterId=1 sourceEndpoint=1 destinationEndpoint=1 options=320 groupId=0 sequence=45>, 46, b'\x00-\x003\x00')
2019-12-05 19:05:08 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0082'
2019-12-05 19:05:08 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401010001014000000086ffc754f1ffff08182d013300002001'
2019-12-05 19:05:08 DEBUG (MainThread) [zigpy.zcl] [0xf154:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=45 command_id=Command.Read_Attributes_rsp>
2019-12-05 19:05:08 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f104010100010140010000822e0000'
2019-12-05 19:05:08 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: initializing channel: from_cache: False
2019-12-05 19:05:08 DEBUG (MainThread) [homeassistant.components.zha.core.channels] [0xf154:1:0x0001]: channel: 'async_initialize' stage succeeded
2019-12-05 19:05:08 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xf154](ZBT-CCTSwitch-D0001): power source: Battery or Unknown
2019-12-05 19:05:08 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0xf154](ZBT-CCTSwitch-D0001): completed initialization

Bind Attempt Log
2019-12-05 19:17:17 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:17:17 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:17:27 DEBUG (MainThread) [homeassistant.components.zha.api] processing binding operation for: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71] cluster: 6
2019-12-05 19:17:27 DEBUG (MainThread) [homeassistant.components.zha.api] processing binding operation for: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71] cluster: 8
2019-12-05 19:17:27 DEBUG (MainThread) [homeassistant.components.zha.api] processing binding operation for: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71] cluster: 768
2019-12-05 19:17:27 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x2f request
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:17:27 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x30 request
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:17:27 DEBUG (MainThread) [zigpy.device] [0xf154] Extending timeout for 0x31 request
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=47>, 50, b'/z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x06\x00\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=48>, 51, b'0z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x08\x00\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xf154, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=49>, 52, b'1z\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x00\x03\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0084'
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0085'
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0086'
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:17:27 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:17:35 DEBUG (MainThread) [bellows.ezsp] Application frame 128 (incomingRouteErrorHandler) received: b'4254f1'
2019-12-05 19:17:35 DEBUG (MainThread) [bellows.ezsp] Application frame 128 (incomingRouteErrorHandler) received: b'4254f1'
2019-12-05 19:17:35 DEBUG (MainThread) [bellows.ezsp] Application frame 128 (incomingRouteErrorHandler) received: b'4254f1'
2019-12-05 19:17:37 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:17:37 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:17:44 DEBUG (MainThread) [bellows.ezsp] Application frame 128 (incomingRouteErrorHandler) received: b'4254f1'
2019-12-05 19:17:44 DEBUG (MainThread) [bellows.ezsp] Application frame 128 (incomingRouteErrorHandler) received: b'4254f1'
2019-12-05 19:17:44 DEBUG (MainThread) [bellows.ezsp] Application frame 128 (incomingRouteErrorHandler) received: b'4254f1'
2019-12-05 19:17:46 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000000218000004001000089ffcc54f1ffff022f00'
2019-12-05 19:17:46 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10000210000004001000084320000'
2019-12-05 19:17:46 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00000021800000400100008affcc54f1ffff023000'
2019-12-05 19:17:46 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10000210000004001000085330000'
2019-12-05 19:17:46 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'00000021800000400100008bffcc54f1ffff023100'
2019-12-05 19:17:46 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'0054f10000210000004001000086340000'
2019-12-05 19:17:46 INFO (MainThread) [homeassistant.components.zha.api] Issue bind devices: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71]
2019-12-05 19:17:47 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:17:48 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:17:58 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:17:58 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:18:08 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:18:08 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:18:18 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:18:18 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:18:28 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:18:28 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:18:38 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:18:38 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-05 19:18:48 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-05 19:18:48 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''

Pairing log looks normal. It bound all clusters it supposed to bind.
Bind attempt log show the request did not go through. Were you binding it to a light? Try again, but press a button on the remote just prior the binding attempt and one more time after you sent the bind request to keep device awake.
Also, in dev panel -> events subscribe to zha_event and press button on the remote. Do you get anything?

I get nothing when listening to zha_event.
I was binding it to a light, and pressing buttons before and after seems to have no effect.

Bind Attempt 2
2019-12-06 17:13:16 DEBUG (MainThread) [homeassistant.components.zha.api] processing binding operation for: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71] cluster: 6
2019-12-06 17:13:16 DEBUG (MainThread) [homeassistant.components.zha.api] processing binding operation for: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71] cluster: 8
2019-12-06 17:13:16 DEBUG (MainThread) [homeassistant.components.zha.api] processing binding operation for: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71] cluster: 768
2019-12-06 17:13:16 DEBUG (MainThread) [zigpy.device] [0xb9b2] Extending timeout for 0x0b request
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-06 17:13:16 DEBUG (MainThread) [zigpy.device] [0xb9b2] Extending timeout for 0x0c request
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-06 17:13:16 DEBUG (MainThread) [zigpy.device] [0xb9b2] Extending timeout for 0x0d request
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (cc:cc:cc:ff:fe:c6:d1:7a, True)
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb9b2, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=11>, 14, b'\x0bz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x06\x00\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb9b2, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=12>, 15, b'\x0cz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x08\x00\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb9b2, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=13>, 16, b'\rz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x00\x03\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0063'
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0064'
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'000401020402010001000099f2abfb36ffff0808130a0000293dff'
2019-12-06 17:13:17 DEBUG (MainThread) [zigpy.zcl] [0x36fb:2:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=19 command_id=Command.Report_Attributes>
2019-12-06 17:13:17 DEBUG (MainThread) [zigpy.zcl] [0x36fb:2:0x0402] ZCL request 0x000a: [[<Attribute attrid=0 value=<TypeValue type=int16s, value=-195>>]]
2019-12-06 17:13:17 DEBUG (MainThread) [zigpy.zcl] [0x36fb:2:0x0402] Attribute report received: measured_value=-195
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'0065'
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b1ffbcb2b9ffff020c00'
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'00b2b900002100000040010000640f0000'
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b2ffbcb2b9ffff020d00'
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'00b2b90000210000004001000065100000'
2019-12-06 17:13:19 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b0ffbbb2b9ffff020b00'
2019-12-06 17:13:20 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-06 17:13:20 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-06 17:13:26 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b6ffbcb2b9ffff020b00'
2019-12-06 17:13:26 DEBUG (MainThread) [zigpy.device] [0xb9b2] Invalid state on future for 0x0b seq -- probably duplicate response
2019-12-06 17:13:26 DEBUG (MainThread) [bellows.ezsp] Application frame 63 (messageSentHandler) received: b'00b2b900002100000040010000630e0000'
2019-12-06 17:13:26 INFO (MainThread) [homeassistant.components.zha.api] Issue bind devices: source_ieee: [cc:cc:cc:ff:fe:c6:d1:7a] target_ieee: [cc:cc:cc:ff:fe:8d:63:71]
2019-12-06 17:13:30 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-06 17:13:36 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event timer_out_of_sync[L]: seconds=5.888581217000137>
2019-12-06 17:13:36 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-06 17:13:46 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-06 17:13:46 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-06 17:13:56 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-06 17:13:56 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-06 17:14:06 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-06 17:14:06 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2019-12-06 17:14:16 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2019-12-06 17:14:16 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''

I tried Touch-Linking a remote to some lights as per the manual, which worked, but all the remotes controlled all of the lights that had been linked. I assume that is not how that is supposed to work, since it is not as helpful.

Nah, actually this time remote did report the successful bind, although it is not clearly shown in the logs:
### Bind request with 0x0b TSN
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb9b2, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=11>, 14, b'\x0bz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x06\x00\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')

### Bind request with 0x0c TSN
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb9b2, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=12>, 15, b'\x0cz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x08\x00\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')

### Bind request with 0x0d TSN
2019-12-06 17:13:16 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xb9b2, <EmberApsFrame profileId=0 clusterId=33 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=13>, 16, b'\rz\xd1\xc6\xfe\xff\xcc\xcc\xcc\x01\x00\x03\x03qc\x8d\xfe\xff\xcc\xcc\xcc\x01')

### Reply to 0x0c TSN with success status (last two bytes)
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b1ffbcb2b9ffff020c00'

### Reply to 0x0d TSN with success status (last two bytes)
2019-12-06 17:13:17 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b2ffbcb2b9ffff020d00'

### Reply to 0x0b TSN with success status (last two bytes)
2019-12-06 17:13:19 DEBUG (MainThread) [bellows.ezsp] Application frame 69 (incomingMessageHandler) received: b'0000002180000040010000b0ffbbb2b9ffff020b00'

So it bound successfully, the question why it still doesn't work. I'd expect it to be able to control the light directly.
@dmulcahey We should collect and log results of https://github.com/home-assistant/home-assistant/blob/c9415ab75d84aedf5a1e667e40c49c3383fcbe91/homeassistant/components/zha/api.py#L560

i'll try to get one tomorrow and reproduce the issue. Per looks, it seems to be quite standard and should just work.

I have a bunch of ideas on how to clean up binding

it is sending group command on ZLL group

2019-12-08 19:16:17 INFO (MainThread) [zigpy.device] [0xbca5] Discovered endpoints: [1]
2019-12-08 19:16:17 INFO (MainThread) [zigpy.endpoint] [0xbca5:1] Discovering endpoint information
2019-12-08 19:16:18 INFO (MainThread) [zigpy.endpoint] [0xbca5:1] Discovered endpoint information: <SimpleDescriptor endpoint=1 profile=260 device_type=2048 device_version=1 input_clusters=[0, 1, 3, 4096, 64769] output_clusters=[3, 4, 6, 8, 25, 768, 4096]>
2019-12-08 19:16:19 DEBUG (MainThread) [zigpy.endpoint] [0xbca5:1] Manufacturer: LDS
2019-12-08 19:16:19 DEBUG (MainThread) [zigpy.endpoint] [0xbca5:1] Model: ZBT-CCTSwitch-D0001

On basic cluster it has attribute id 0x000B which reads www.xxxx.com 🤷♂

On basic cluster it has attribute id 0x000B which reads www.xxxx.com 🤷♂

Wtf??? LOL

Apparently this device doesn't do direct binds, even though it replies with success to bind request operations.
But soon, like really soon (next year) we're going to have Device Group management, then you could add the lights to the same group as this remote and control them at once directly.

My goal is to have the UI PR’s opened by the end of the weekend :)


Replace underscore with lodash

Replace underscore with lodash since lodash is more performant.

For the record, I'm not especially interested in switching to lodash. I haven't seen any evidence that Underscore is creating performance bottlenecks in JSDoc.


Add minimum DPF version logic to examples

Tested locally and works for gallery generation, like here with 00-basic_example.py declared as requiring 6.2 in a note:


Reset view position when near end of file

Bug
View position of video is saved even when you have watched video until the end, making it next time just skip to the end.
To Reproduce
Steps to reproduce the behavior:

Go to video
Skip to end and wait video to finish
Click next video
Click back to first video, it will skip at the end.

Expected behavior
Reset view position when near end of file

Closed by #6976


Add error catching for Faraday errors

Added error catching for other Faraday errors other than timeout. Reduced timeout to 5 seconds.
Also removed the constituency info from the petition creation replay stage.

LGTM :+1:

Probably better would be to do it in two separate commits (removing the constituency info) - no need to change it now though, just heads up for the next time:)
LGTM :cake:


Investigate pooling TagHelperContext.Items

We currently construct a brand new items dictionary for every TagHelper instance. We investigate if we can pool these.
@mnltejaswini can provide perf numbers.

I'm prospectively moving this to post-RTM.

I think this should be post-RTM'ed again. We have bigger fish to fry.

I don't think we can do this


Optimize huglin and bedd for dask with flox

Pull Request Checklist:

[x] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes #1494

[x] Tests for the changes have been added (for bug fixes / features)

[ ] (If applicable) Documentation has been added / updated (for bug fixes / features)

[x] CHANGES.rst has been updated (with summary of main changes)

[x] Link to issue (:issue:number) and pull request (:pull:number) has been added

What kind of change does this PR introduce?
Changes the use of aggregate_between_dates to a select_time(...).resample().sum(). One of the "strength" of aggregate_between_dates is the possibility to have those days change from year to year.  In huglin_index and biologically_effective_degree_days, we are using fixed start and end dates, so I was able to perform the same operation with a simpler function.
This change makes xarray aware of our resampling-sum computation and thus performance optimizations implemented by  flox are made accessible!
In order to preserve the signature and functionality, I had to make select_time a bit more flexible so that we can choose if the bounds are inclusive or not. (aggregate_between_dates has a non-inclusive end-bound, which select_time is inclusine by default).
The results are different, but with a relative error around 1e-7, my guess is that this comes from the optimization itself (dask) and should be considered noise.
I think calendar support is preserved. I have found issues with using leap years, non-uniform calendars, etc. However, this change now allows passing 02-30 as a start or end date if the input uses 360_day. Haha, pretty sure that's almost useless, but it's there anyway.
The biggest difference is that the xclim.indices versions do not mask incomplete periods anymore. With aggregate_between_dates, if the  end_date did not exist in the period, the output would be NaN. This is not the case with select_time. The indicator is unchanged since the missing check will mask the incomplete period.
Does this PR introduce a breaking change?
I don't think the last element in a breaking change because:

Indicators should always be used (especially if missing data are an issue)
I prefer that the indice doesn't perform "checks" that the indicator should be doing

Other information:
This brings down the usage of aggregate_between_dates to a single function : effective_growing_degree_days. As the dates are there a function of the year, we can't use  select_time. To be optimized in the future!

@fjetter, turns out we already had the tools needed for an optimized version of huglin_index!

One of the "strength" of aggregate_between_dates is the possibility to have those days change from year to year. I

This is definitely very possible using flox directly. 80% of a groupby problem is just constructing the group labels. You should be able to do this somewhat easily with pandas.
Here's how xarray does it for the resampling problem: https://github.com/pydata/xarray/blob/1b0012a44aa45c67858489bc815928e1712dbd00/xarray/core/groupby.py#L536-L541
These codes are passed to flox.xarray.xarray_reduce


Bump jsonschema to 4.17.1

Since 4.2.0, jsonschema uses importlib.resources to load schemas, fixing an incompatibility with PyOxidizer.
See https://github.com/python-jsonschema/jsonschema/pull/873
I tested this manually by removing an operation-type key, and got this as expected:
ERROR] Cannot race. Traceback (most recent call last):
  File "/home/q/src/rally/esrally/track/loader.py", line 1059, in read
    jsonschema.validate(track_spec, self.track_schema)
  File "/home/q/.virtualenvs/rally/lib64/python3.11/site-packages/jsonschema/validators.py", line 1120, in validate
    raise error
jsonschema.exceptions.ValidationError: 'operation-type' is a required property

Hmm, it allows compilation but breaks at runtime now: https://github.com/indygreg/PyOxidizer/issues/457. Closing for now.


PROT-104: Change env to Mainnet in GlobalSnapshotConsensusFunctionsSuite

Overview
Small cleanup of a testing flag that was used during the migration to 2.0
Approach

Removed hardcoded testnet definition that is no longer needed in test
Cleaned up env param that was no longer used

Testing

ensured unit tests pass
all CI checks pass

Tickets

closes PROT-104

Remember about adding labels to every PR - generating changelog depends on it

@scasplte2 please set the label for this PR

Apologies for missing the label @TheMMaciek. Will be sure to follow the contributing guidelines in the future.

force pushes above were to rebase with develop since I had merged previously


fixing draft 6 & 7 non-id tests

Fixes a couple tests recently merged as part of #471

doh, thanks!


refactor(shared-data): Make a protocol schema v7 draft

Overview
This PR creates a draft of protocol schema v7.
Closes Jira RLAB-68. See that ticket for reasoning.
Changelog

Create protocol/schemas/7-draft.json.

It is identical to protocol/schemas/6.json, except with references to 6 replaced with 7.

Create a simpleV7.json fixture.

It is identical to simpleV6.json, except with references to the v6 schema replaced with the v7 schema draft.

Create basic tests to make sure the schema functions as intended.

These are identical to the tests for v6.

For debuggability, swap the order of some asserts in our schema tests. Now, when they fail, they'll print out a reason why, instead of just "expected true but got false".

Review requests
Risk assessment
No risk to production code.

Maybe this is the right PR to add schema v7 to the python side as well?

Discussed with @b-cooper in-person. I'd rather postpone any meaningful Python and TypeScript changes until we actually need them for something. That way, we keep revisions to this draft cheap and easy.


@localCopy throws "same computation" assertion for Ember 3.16

Refactored a component to Glimmer, and used @localCopy for the behavior previously implemented with a CP. This however throws the following assertion in some cases at this line
Error: Assertion Failed: You attempted to update `value` on `Meta`, but it had already been used previously in the same computation.  Attempting to update a value after using it in a computation can cause logical errors, infinite revalidation bugs, and performance issues, and is not supported.

The best reproduction I have at hand is this PR. The full error stack can be seen in CI here.
A brief outline how things work together here:

isSelected is defined to be a local copy of this.args.selected here
isSelected is passed down to a sub component here
the sub component consumes this (as this.args.selected) in this getter here. Note when I remove reading from this.args.selected here, the error is not thrown anymore, but of course the component does not work correctly anymore. But at least it shows the definite place where the original localCopied property is consumed...
when setting a property passed to @selected (of the parent component, see 1.) here, the mentioned assertion is thrown.

Note 1: this only happens for Ember 3.16 (or eventually more versions not covered by ember-try scenarios). It does not happen for 3.20, or the current release, beta or canary scenarios! So maybe the root issue is in that version of Ember, and has been fixed later?
Note 2: Previously the Ember.Component based implementation used a very simple CP-based solution for the same behavior as localCopy here, which did not suffer from this.
Note 3: similar sounding issue report in https://github.com/pzuraq/tracked-toolbox/issues/7

I tracked this down a bit further regarding the Ember versions: 3.16 (didn't test earlier versions) to 3.20.3 show this error, but starting from 3.20.4 this seems fixed. Not sure what change could have caused, maybe just on of the GlimmerVM updates? https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md#v3204-august-11-2020
Given that I need to support 3.16, and this addon says it supports 3.8, it would be nice to get this fixed nevertheless.
@pzuraq do you see any chance, or is this something that can only be fixed upstream? (I assume the changes that fixed this in 3.20.4 won't get backported to 3.16, even though it's still an active LTS?)

I tried to verify if it's related to the Glimmer VM updates. It doesn't seem so.
<EMAIL_ADDRESS>uses ^0.55.1 and<EMAIL_ADDRESS>uses ^0.56.1. I run the feature branch reproducing the issue (https://github.com/kaliber5/ember-bootstrap/pull/1226) against both versions. I can confirm that v3.20.3 is failing, while v3.20.4 is passing.
To verify if it's related to Glimmer VM updates I used yarn resolutions to enforce Glimmer VM ^0.56.1 with<EMAIL_ADDRESS>diff --git a/package.json b/package.json
index 9335edbb..e5832aac 100644
--- a/package.json
+++ b/package.json
@@ -103,7 +103,7 @@
     "ember-resolver": "^8.0.2",
     "ember-sinon": "^5.0.0",
     "ember-sinon-qunit": "^5.0.0",
-    "ember-source": "~3.20.4",
+    "ember-source": "3.20.3",
     "ember-source-channel-url": "^3.0.0",
     "ember-template-lint": "^2.11.0",
     "ember-try": "^1.4.0",
@@ -179,5 +179,15 @@
   },
   "lint-staged": {
     "*.js": "eslint --cache --fix"
+  },
+  "resolutions": {
+    "@glimmer/compiler": "^0.56.1",
+    "@glimmer/interfaces": "^0.56.1",
+    "@glimmer/node": "^0.56.1",
+    "@glimmer/opcode-compiler": "^0.56.1",
+    "@glimmer/program": "^0.56.1",
+    "@glimmer/reference": "^0.56.1",
+    "@glimmer/runtime": "^0.56.1",
+    "@glimmer/validator": "^0.56.1"
   }
 }

Tests are still failing.
I verified that v0.56.1 is actually used:
$ yarn list --pattern "@glimmer|ember-source"
yarn list v1.22.5
├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>└─<EMAIL_ADDRESS>   ├─<EMAIL_ADDRESS>   └─<EMAIL_ADDRESS>Done in 1.03s.

To double check I compared the installed packages for<EMAIL_ADDRESS>for which the feature branch is passing. No difference except for ember-source on that packages:
$ yarn list --pattern "@glimmer|ember-source"
yarn list v1.22.5
├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>├─<EMAIL_ADDRESS>│  └─<EMAIL_ADDRESS>└─<EMAIL_ADDRESS>   ├─<EMAIL_ADDRESS>   └─<EMAIL_ADDRESS>Done in 2.12s.

Not sure if I missed something. Tried to document my steps as detailed as possible so that you can verify if my findings are correct.

Given this is resolved on current versions of Ember, and that the latest version of the library requires at least Ember 3.24, I'm closing this. Folks who hit it should upgrade Ember to the current LTS (which is the best path forward for folks just starting on Octane anyway)!


can not install app via catalog app

Describe your issue here
Failed to install app longhorn-system. Error: UPGRADE FAILED: Get https://localhost:443/k8s/clusters/c-kbbtz/api/v1/namespaces/longhorn-system/configmaps?labelSelector=NAME%!D(MISSING)longhorn-system%!C(MISSING)OWNER%!D(MISSING)TILLER%!C(MISSING)STATUS%!D(MISSING)DEPLOYED: dial tcp [::1]:443: connect: cannot assign requested address

Useful
Info

Versions
Rancher v2.2.4 UI: v2.2.70

Route
authenticated.cluster.monitoring.index

i have install rancher &  k8s at same vm, the rancher ui by using ip:8443.


Where can I find the extrinsic parameters?

Thank you for providing this useful fetcher! I want to project the 3d poses into the image however I could not find the extrinsic parameters to do so. Would you be able to provided that as well?

I just realized that the 3d poses are in camera coordinate. This means I can project them to the image using just the intrinsics.
In case anyone is interested I took the extrinsics from here: https://github.com/karfly/human36m-camera-parameters/blob/master/camera-parameters.json

@lcit I have a question. Does human3.6m data set contain camera parameter information? In the download file, there are 8 cdf files for each action in D3_position_mono_universal. What do they mean? cdf stores 3D coordinates. What is HZ? How does it correspond to video?


T´throw exception if none of the accepted mimeTypes matches

Codecov Report

Merging #69 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master      #69      +/-   ##
============================================
+ Coverage     98.62%   98.65%   +0.03%
- Complexity      107      110       +3
============================================
  Files            22       23       +1
  Lines           290      297       +7
============================================
+ Hits            286      293       +7
  Misses            4        4

Impacted Files
Coverage Δ
Complexity Δ

src/Negotiation/ContentNegotiator.php
100.00% <100.00%> (ø)
10.00 <0.00> (+1.00)

src/Negotiation/NotNegotiableException.php
100.00% <100.00%> (ø)
2.00 <2.00> (?)

src/Serialize/FormatException.php
100.00% <100.00%> (ø)
2.00 <0.00> (ø)

Continue to review full report at Codecov.

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


Is there any way to get log of terminal output like pytty.log

You can use http://linux.die.net/man/1/script

I am streaming web socket conversation into file. Thanks for your reply

OK, closing this.


feat: add updater commands to cli.App, variadic arguments

What this PR does: This PR reworks the updater to support being attached to a given cli.App, among other options and deprecates the NeedsUpdate function.
The updater now exposes the following commands onto a cli.App:
NAME:
   devenv updater - Commands for interacting with the built-in updater

USAGE:
   devenv updater command [command options] [arguments...]

COMMANDS:
   set-channel    Set the channel to check for updates: release or rc
   rollback       Rollback to the previous version
   list-releases  List all releases
   help, h        Shows a list of commands or help for one command

OPTIONS:
   --help, -h  show help (default: false)

set-channel: Takes rc or release, allowing the user to enable/disable pre-releases. This calls the updater after setting the channel.
rollback: rolls back to the last updated version, or can pass a version in to --version
list-releases: complements rollback by wrapping a gh release list call. Seemed easier than implementing all that code.

Note: When on a pre-release version you'll always be subscribed to the rc channel until the next stable version comes out, as usual. This allows users an easy way to get back onto stable in the future. If one wants to use rc forever, set-channel must be called.

Still need to make a few passes on the code, but wanted to get feedback from the team!

Pull Request Test Coverage Report for Build 591bbb44-6713-4a03-ba6e-ed7d2fc9856e

0 of 434 (0.0%)  changed or added relevant lines in 6 files are covered.
18 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-3.7%) to 55.523%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/cli/bootstrap.go
0
12
0.0%

pkg/updater/options.go
0
32
0.0%

pkg/updater/misc.go
0
49
0.0%

pkg/updater/config.go
0
65
0.0%

pkg/updater/updater.go
0
103
0.0%

pkg/updater/cli.go
0
173
0.0%

Files with Coverage Reduction
New Missed Lines
%

pkg/cli/bootstrap.go
2
4.61%

pkg/updater/updater.go
16
0%

Totals

Change from base Build 68356a62-bf5d-45c9-af06-49de3c0607ba:
-3.7%

Covered Lines:
2081

Relevant Lines:
3748

💛  - Coveralls

Opening for more feedback, still a little bit left to do


segmentation fault in example

I have followed commands introduced in README in order to run examples, but it failed in segmentation fault.
Here is my environment.
chainer version:3.5.0
OS:mac OS High Sierra version 10.13.4
Anaconda version:4.5.0
I created chainer-env via Anaconda following commands below.
$ conda create -c rdkit -n chainer-env rdkit
$ conda activate chainer-env
$ pip install chainer
$ conda install scikit-learn, pandas, tqdm
$ git clone https://github.com/pfnet-research/chainer-chemistry.git
$ pip install -e chainer-chemistry

Next I tried to run the example introduced in README.
But unfortunately these commands ended up with segmentation fault.
$ cd chainer-chemistry/examples/tox21
$ python train_tox21.py --method=nfp  --gpu=0
zsh: segmentation fault  python train_tox21.py --method=nfp --gpu=0

I investigated this case and found the following might be the cause of this problem.
$ python
>>> import chainer
>>> import rdkit # this works
$ python
>>> import rdkit
>>> import chainer
segmentation fault

Say, import rdkit after import chainer works but the opposite does not.

I had the same problem on macOS (High Sierra 10.13.4, conda 4.4.10, python 3.6.4, rdkit 2<IP_ADDRESS>). This may be related to rdkit/rdkit#1617. I'm looking for a workaround.

Your solution worked in my environment.
Thank you!

@fullswing Can I close this PR as it is not a problem of Chainer Chemistry?

Sorry, I will.


Problem with GPIO / pinMode

Hi
I use
b.pinMode( outpin[j], b.OUTPUT , 7, 'pullup', 'fast', function (x) {} );
where outpin[j] is e.g. P8_31 or almost whatever.
I get this:
/usr/local/lib/node_modules/bonescript/index.js:161
if(typeof resp.err != 'undefined') {
^
TypeError: Cannot read property 'err' of undefined
at Object.f.pinMode (/usr/local/lib/node_modules/bonescript/index.js:161:19)
at Object.event [as /stream](/home/debian/nodeSofta/requestHandlers.js:287:                                                                                19)
at route (/home/debian/nodeSofta/router.js:4:25)
at IncomingMessage. (/home/debian/nodeSofta/server.js:18:13)
at IncomingMessage.EventEmitter.emit (events.js:92:17)
at _stream_readable.js:920:16
at process._tickCallback (node.js:415:13)
Actually even for simpler versions I get the same message. E.g. for
            b.pinMode( outpin[j], b.OUTPUT );

Beaglebone version is 2.4. OS was Debian with node.js 10.*

This issue was moved to beagleboard/bonescript#29


Updating macOS release manifest susceptible to race conditions

Since https://flutter.googlesource.com/infra/+/2b10a1dc69802744cd4d8600e13f4897bae1f83b^!/#F3, we have started building release packages for both arm64 and x64 on macOS. These are packages are created by the script: https://github.com/flutter/flutter/blob/master/dev/bots/prepare_package.dart. What this script roughly does is:

check out the flutter/flutter repo at the desired release branch and revision
run flutter precache --all-platforms
compress the SDK directory
upload it to storage.googleapis.com/flutter_infra_release/releases/$CHANNEL/$HOST_PLATFORM/$ARCHIVE
download the manifest JSON (which gets consumed by the website) from storage.googleapis.com/flutter_infra_release/releases/releases_${HOST_PLATFORM}.json
update the manifest with the current release
re-upload the updated manifest file.

The problem is that if we are scheduling concurrent macOS packaging builds (one for ARM64, one for x64), both builds could download the same manifest in step 5, but then whichever build reaches step 7 last could overwrite the changes from the other.
To solve this, I think we need to either:
a) have the two architectures use separate manifest files, and update the website to merge them when rendering the website; or
b) implement some kind of locking and polling setup. However, I'm not sure if even this would not be susceptible to race conditions, unless GCS provides a way to atomically set a lock if it is not already locked, and fail otherwise.

cc @XilaiZhang, @CaseyHillers, @itsjustkevin

Is this something that would be true for all the packaging builders, such as linux and windows?
We could use GCS Bucket Locking for (B)

Is this something that would be true for all the packaging builders, such as linux and windows?
We could use GCS Bucket Locking for (B)

I don't believe we build linux and windows for multiple architectures...yet.

Is this something that would be true for all the packaging builders, such as linux and windows?
We could use GCS Bucket Locking for (B)

Unfortunately GCS bucket locking does not put a mutex lock on a bucket, but rather prevents future changes to the bucket's retention policy.
Per this SO answer from 2019, GCS simply does not support locking: https://stackoverflow.com/questions/54768768/gcs-file-locking-query.
It sounds like we could use generation numbers and request preconditions to cause a write to fail if the current generation number isn't the same one as when we first read the file: https://cloud.google.com/storage/docs/metadata#generation-number

Looks like when we write, we can add the precondition like so:
gcloud storage cp OBJECT_LOCATION gs://DESTINATION_BUCKET_NAME --if-generation-match=GENERATION

https://cloud.google.com/storage/docs/request-preconditions#cost_of_preconditions
We would just need to ensure we already have the GENERATION number from when we read the file.


added a github action for raylib 5.5

Updated github actions to package and release raylib 5.5 dist
ps. someone familiar with github actions should probably verify, since im not at all familiar with github actions.

Looks fine to me.


Issue #DP-711 Task: Download Contribution Dashboard table as csv

@pallakartheekreddy - Please review and merge.


qtwebkit: add missing flex-native dep

Thanks, in master-next now.

Merged in zeus and master now.


Pass --write-service-info to every Android Dart isolate

Pass --write-service-info to every Android Dart isolate
Value should be "service_info.json"

Can you add a bit more background for the reasoning?

@blasten would you mind providing that background?

Is this for the attach?

Yep — this is to discover the observatory Uri.

Looks like we're going a different route to solve this problem. I'm going to close this issue.


Increase max connections to reduce chance of eclipse attacks

If there are still a large number of non-classic nodes when the hard fork activates regular nodes may create what is effectively an eclipse attack, this should significantly reduce the likelihood of that happening.

Please explain why you think this is better, and please give some testing output you gathered that led you to these magical values :)
I'm sceptical that this will work on NATed nodes, what do you think about that?

NACK.  The key is to spend less time reviewing these than it takes to create them.

@zander The MAX_OUTBOUND_CONNECTIONS variable increases the amount of connections being established from nodes even those behind NAT which increases the likelyhood of getting a connection with another node that will relay blocks on the new chain. The DEFAULT_MAX_PEER_CONNECTIONS change increases the amount of allowable inbound connections for those that are not behind NAT close to the select() limit so that nodes accepting connections have plenty of connection space for nodes behind NAT.

It would be superior to program Classic to not connect to Core useragents.

Merge window is open only for 2 MB HF stuff.
An exception for this PR is not justified. A vote has been started on consider.it. It does not appear to be a favorable change.
I am closing this. It may be reopened after the fork.

Concept ACK
Improving interconnectivity during hard forks is pretty important. (but there may be more efficient ways to do it)

Come on, Peter, you should know better than that.

That's why I said "Concept ACK", noting that this addresses a real issue, but there may be more efficient ways to do it. If I had thought this change should be merged as-is, I'd have said ACK or utACK.


Bug: Market order submission not returning 'Insufficient funds' error

Hi,
As with my previous bug report this appear to be an exchange side bug rather than a bug with this client library (which I do not use) and so if there is a more appropriate place to report this please let me know.
The issue
Submitting market orders whilst not having sufficient funds does not always result in an 'Insufficient funds' error response.
The precise circumstances under which this occurs is not completely clear, from experimentation it appears to occur for 'buy' market orders but not for 'sell' market orders.
I also observe that when this problem occurs we are sent a 'received' message for the order however the 'size' field is 0.
In summary:
Sell BTC-USD (with zero BTC in account) -> 'Insufficient funds' error returned from POST call
Buy BTC-USD (with zero USD in account) -> no error returned from POST call but 'received' shows size as 0
See also this bug report for another example of this issue occurring when using market orders with 'size' but not occurring when using 'funds'.
Note this issue was observed on the 'sandbox' environment, I have not attempted to reproduce it on the live trading system.
If needed I can produce a minimal reproducible example to demonstrate the bug.
Thanks,
Fuji Apple

Out of curiosity how does your order look like? Are you using size or funds field for you market buy order. I ask because limit buy, sell and market sell orders all use size whereas market buy orders use funds field in the order message.
I just tested on the live exchange and placing a market order with zero USD fails to place when specifying the order as funds: $100 but succeeds as a $0 market order when specifying the order as size: 0.002. I believe this is because specifically for market buy orders gdax is looking for the funds field and if it doesn't see it is setting to max available balance. I tested this by placing a market buy order for size: 0.1 (around $700) but with only $10 in my USD balance. The order succeeds using the total available balance so basically they are automatically fitting it to your available balance and a $0 balance is included as an acceptable value.

@sfkiwi - thank you for your reply.  Your testing results are inline with what @mfxuus reported in the issue linked above (i.e. works for funds but not always for size).
In my case I am only using size for both buy and sell orders which, as i interpret the documentation, is valid:

market order parameters
size | [optional]* Desired amount in BTC
funds | [optional]* Desired amount of quote currency to use

One of size or funds is required.

I could of course calculate the corresponding funds for a given buy order size to workaround the bug (as it happens I have another workaround in place) but I think it would be best for GDax to fix the issue.
As an aside, I notice in the GDax web UI that for buy orders you are only able to specify funds (i.e. USD amount to sell) which I find very non-intuitive - I guess it is considered more user friendly as it is similar to how retail Bureau de Change works which people may be more comfortable with rather than FX markets conventions of buying/selling the FX ticker.
Thanks,
Fuji Apple


[NOMRG] UX: Display errors as summary/details elements

Changes proposed in this pull request
Uses https://github.com/poldracklab/niworkflows/pull/464 to generate reports. Check the output of ds054 for an example error, when it's run.
Closes #1991.
Documentation that should be reviewed

Here's an example report with an error: https://12090-53175327-gh.circle-artifacts.com/0/tmp/ds054/derivatives/fmriprep/sub-100185.html
@dmd Any comments?

I've canceled the non-ds054 tests. We'll have a full run before any release on the off chance that this is somehow affecting other tests.

No point merging, since we're going to have a couple bug fixes in niworkflows 1.1.8. Will keep open until we release niworkflows and update the PIN.

Here's an example report with an error: https://12090-53175327-gh.circle-artifacts.com/0/tmp/ds054/derivatives/fmriprep/sub-100185.html
@dmd Any comments?

Exactly what I envisioned, thanks.

Included in 2590fed406a77874f6ab5dc498d246bc0f0db4bc.


🔧(make) use docker compose command when available

Purpose
In the makefile, we detect if docker compose 2 is used and use docker compose command instead of the compatibility layer docker-compose. Using docker-compose often lead to removing the db container.
Proposal

[x] use docker compose command when available

Fixes #1925

OK on win WSL with docker-compose v1

I am not sure about the expected behavior, but this fixup set DOCKER_COMPOSE_VERSION every time to 2, even when I set docker compose to the V1.
Before the fixup DOCKER_COMPOSE_VERSION was set according to my docker compose version running.

I am not sure about the expected behavior, but this fixup set DOCKER_COMPOSE_VERSION every time to 2, even when I set docker compose to the V1. Before the fixup DOCKER_COMPOSE_VERSION was set according to my docker compose version running.

This fixup does 2 things. First it test if the docker compose command is available and if yes, it test the output version.
If you run docker compose version --short, what is the output you have ?


Remove HashAlgo typeclass, specialize to blake2b

PR checklist:

[x] Test coverage for the proposed changes
[x] PR description contains example output from repl interaction or a snippet from unit test output
[x] Documentation has been updated if new natives or FV properties have been added. To generate new documentation, issue cabal run tests. If they pass locally, docs are generated.
[x] Any changes that could be relevant to users have been recorded in the changelog
[x] In case of  changes to the Pact trace output (pact -t), make sure pact-lsp is in sync.

Additionally, please justify why you should or should not do the following:

[ ] Confirm replay/back compat
[x] Benchmark regressions
[ ] (For Kadena engineers) Run integration-tests against a Chainweb built with this version of Pact

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1204423075448356

integration tests + replay is blocked by failing master of chainweb-node.

This will not land, all of this work is superceded by pact-5, so I will close this PR.


Dead websites

Gitea version (or commit ref): N/A
Git version: N/A
Operating system: N/A
Database (use [x]): N/A
Can you reproduce the bug at https://try.gitea.io: N/A
Log gist: N/A

Description
A lot of Gitea-related websites are down:

~https://drone.gitea.io/go-gitea/gitea (No response)~
https://try.gitea.io/ (No response)
~https://gitea.io/ (Cloudflare Always Online response)~

I have put a copy of the docs on my server for now: https://docs.gitea.io.geek1011.net if anyone wants them. Also, for people who want to build gitea, clone the github repository into $GOPATH/code.gitea.io/gitea

I have put a copy of the docs on my server for now: https://docs.gitea.io.geek1011.net if anyone wants them.
@geek1011 Your link returns 404 page not found

oops. I will need to fix that, it was working fine yesterday.
On Jul 24, 2017 8:44 AM, Jonas Franz<EMAIL_ADDRESS>wrote:
I have put a copy of the docs on my server for now: https://docs.gitea.io.geek1011.net if anyone wants them.
@geek1011https://github.com/geek1011 Your link returns 404 page not found
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/go-gitea/gitea/issues/2202#issuecomment-317410993, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANQ-1cP2Wu49goF-Z_j8lSyrB_YrCx4Gks5sRJGlgaJpZM4OgZwa.

I have set up a clone of the whole site here: https://gitea.tk

@geek1011 gitea.tk seems down for me.

@JonasFranzDEV Not anymore, I was just doing maintenance.

docs.gitea.io and blog.gitea.io are now up again

We are working on this.

code.gitea.io and gitea.io are now up again

lgtm up again

drone is temporarily up, need to check server-loads

coverage.gitea.io is offline so ervy buiild will fail.

dl.gitea.io still down

Now all the services up!

First: Glad to read all is up again! Is it permitted to ask what had brought things down?

We have been sponsored by Digital Ocean but it's not any more. We have a new sponsor now.

Thanks for the prompt reply – and glad to read you've got a (new) sponsor (and are not "left in the dark"). :+1: – and keep up the good work – while we keep spreading the word :stuck_out_tongue_winking_eye:

I noticed dl.gitea.io, discourse.gitea.io, drone.gitea.io can be reached anyway. But looks like gitea.io, docs.gitea.io and try.gitea.io frequently disappear. Assuming possible cause is blocking in Russia where I live.


fix arguments mixup for sqf displayctrl command

Rdy? We'll need to remove the const& for the display parameter before helper classes arrive. But there's still some:tm: time till then.