search

Yoda-x / ha-zha-new

update of the zha component
56 stars 10 forks source link

Support for HA version of NYCE sensors? #47

Closed MYeager1967 closed 5 years ago

MYeager1967 commented 6 years ago

Any chance this will allow the use of NYCE tilt and hinge sensors? They are the HA versions and not the Iris ones...

Yoda-x commented 6 years ago

Hi, there is a smart-things groovy file on their homepage. From what I see, it should be possible without big problems. It's likely a IAS sensor, which is supported. If they follows the zigbee specs, it may work out of the box, otherwise a custom device file is needed.

MYeager1967 commented 6 years ago

Right now, it's paired to my Vera Plus. Being as that's the case, I would have thought it would have paired. The database has an entry, but the LEDs blink to indicate it's looking for the network. I can't seem to get your files installed so that the configuration entry zha_new can see them either. I'm doing the virtual environment and I activated it before I issued the installation command.

Yoda-x commented 6 years ago

I updated my code recently.Please try out the preview branch, it should also load the required modules itself. You can check with pip list if my versions (x.x.x-Y.pre) are used if you don't see the sensor in the web interface please provide the log files with debugging enabled.

Thanks

MYeager1967 commented 6 years ago

I'll try again to get your files loaded. Last time, the configuration entry of zha_new kicked back..

On Tue, Sep 11, 2018, 6:31 PM Yoda-x notifications@github.com wrote:

I updated my code recently.Please try out the preview branch, it should also load the required modules itself. You can check with pip list if my versions (x.x.x-Y.pre) are used if you don't see the sensor in the web interface please provide the log files with debugging enabled.

Thanks

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Yoda-x/ha-zha-new/issues/47#issuecomment-420448410, or mute the thread https://github.com/notifications/unsubscribe-auth/AEwS9kNNfyxJB_EzOKPC0TnnVYeq7SMUks5uaDnUgaJpZM4WgCew .

Adminiuga commented 6 years ago

I've got NYCE NCZ-3014-HA tilt sensor and I couldn't get it working. Not with upstream zha nor with zha_new. In both cases it behaves the same and very similarly to Bosch motion sensors: it joins the network, CIE is written to the device and then device leaves the network a few moments later. Here's the log

Now, I'm running the preview branch of zha_new in a docker and I've modified the requirements to be

REQUIREMENTS = [
    'https://github.com/Yoda-x/bellows/archive/preview.zip#bellows==0.7.2-pre',
    'https://github.com/Yoda-x/zigpy/archive/preview.zip#zigpy==0.1.3-Y-pre'
]

But I have hard time validating what is the actual version of bellows & zigpy. In the homeassistant.log I see 

2018-09-12 21:42:38 WARNING (MainThread) [homeassistant.loader] You are using a custom component for zha_new which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2018-09-12 21:42:38 INFO (SyncWorker_1) [homeassistant.util.package] Attempting install of https://github.com/Yoda-x/bellows/archive/preview.zip#bellows==0.7.2-pre

but running docker container exec ha pip3 list | grep bellows does not produce any output, so I'm not quite sure where it was installed

Adminiuga commented 6 years ago

i've got the pip3 issue solved. There's an error in my updated dependencies, the bellows should be #bellows==0.7.2-Y-pre. Had to install git into container, in order to be able to update zigpy & bellows. Here's output for pip3 list

user@host:~/user/src/yoda-x/ha-conf$ docker container exec yoda-x-ha pip3 list |egrep '(bellows|zigpy)'
bellows                           0.7.2-Y-pre 
zigpy                             0.1.3-Y-pre 
zigpy-xbee                        0.1.1

Going to try the sensor again... And here's another log, but the results are the same. Joins and then leaves

Yoda-x commented 6 years ago

Yes, looks strange. From what I see the sensor accepts the ciee write and the zone read. The only difference I see in relation to the nyce script for SmartThings is reading of the battery attributes and the setting of the attribute report for the battery. This may be a secret key, don't know. I will create a DH file to add this to the init process. What is the status of the LEDS for 2x button-press (network status) and after/during pairing ?

I also was experimenting with the container, even if not realy use it (using venv). I did not needed git, as the links are just https urls. opening a console in the running container, doing the pip install -U with the dependency links and then restarting the the container was fine for me. I used the latest official container from docker-hub.

PS: I asked the nyce support about this problem, lets see...

Adminiuga commented 6 years ago

I did not needed git, as the links are just https urls. Yep, I think if I had correct URL in the dependencies, the I wouldn't need it, but installing it through pip3 install --update git+https://... required me to have git installed in the docker, which makes sense.

What is the status of the LEDS for 2x button-press (network status) and after/during pairing ? so this happens quite quickly and I don't have enough time to get 2 presses, while device is still joined. But other than that, it goes through:

  1. yellow/red/yellow -- while joining
  2. joins than leaves
  3. red/red/red -- on two presses after that

I'll try no to do anything with the IAS cluster, to see if it could just get the battery. I couldn't find anything special in Smart Things DH, but I can read those handlers only at somewhat high level and don't understand all the inner workings of it. The one thing not clear to me is the following code:

def enrollResponse() {
    [
        // Enrolling device into the IAS Zone
        "raw 0x500 {01 23 00 00 00}", "delay 200",
        "send 0x${device.deviceNetworkId} 1 1"
    ]
}

is it sending from source_endpoint=1 to dest_endpoint=1 on cluster 0x500 [01, 23, 00, 00, 00] bytes? I'm assuming it is triggered when DH receives "enroll_request" command, so it must be "enroll_response" command, right? but does it look like an "enroll_response" command or like "initiate normal operation mode"?

Yoda-x commented 6 years ago
  1. ok, if you use git+http: you need git, I just used the URL (without git+) as it is.
  2. there is good explanation for the raw command and it's the enroll_response command. But going through the smartthings forum, it may be a good idea to send the response, even if there was no request received...
Yoda-x commented 6 years ago

it seems the enroll request is mandatory, this is one out of 3 options from the spec to enroll an ias-zone:

Auto-Enroll-Response
1. After an IAS Zone server is commissioned to a network, the IAS CIE MAY perform service discovery.
2. If the IAS CIE determines it wants to enroll the IAS Zone server, it SHALL send a Write Attribute
command on the IAS Zone server’s CIE_IAS_Address attribute with its IEEE address.
3. The IAS Zone server MAY configure a binding table entry for the IAS CIE’s address because all of
its communication will be directed to the IAS CIE.
4. The IAS CIE SHALL send a Zone Enroll Response, which assigns the IAS Zone server’s ZoneID
attribute.
5. The IAS Zone server SHALL change its ZoneState attribute to 0x01 (enrolled).
Yoda-x commented 6 years ago

ok, next try. please get a fresh copy of the zha_new from preview

Adminiuga commented 6 years ago

I thought I've tried sending "enroll_response", but it didn't fix it. I wonder if it cares about TSN==23. I'll give it another try with your version.

this is what i've tried previously

        from zigpy.exceptions import DeliveryError
        try:
            ieee = self.cluster.endpoint.device.application.ieee
            v = await self.cluster.write_attributes({'cie_addr': ieee})
            _LOGGER.debug("%s: IAS wrote ieee: %s", self.entity_id, v[0])
            #v = await self.cluster.bind()
            #_LOGGER.debug("%s: successfuly bound '%s' cluster: %s",
            #              self.entity_id, self.cluster.name, v[0])
            v = await self.cluster.enroll_response(0, 0)
            _LOGGER.debug("%s: IAS_CIE enroll_response: %s", self.entity_id, v)
            v = await self.cluster.init_normal_op_mode()
            _LOGGER.debug("%s: IAS init normal op mode: %s", self.entity_id, v)
        except DeliveryError as ex:
            _LOGGER.error(
                "%s: couldn't configure IAS zone: %s", self.entity_id, str(ex)
            )
MYeager1967 commented 6 years ago

Watching this closely, wish I had enough knowledge to help. 😁

On Thu, Sep 13, 2018, 1:00 PM Alexei Chetroi notifications@github.com wrote:

I thought I've tried sending "enroll_response", but it didn't fix it. I wonder if it cares about TSN==23. I'll give it another try with your version.

this is what i've tried previously

    from zigpy.exceptions import DeliveryError
    try:
        ieee = self.cluster.endpoint.device.application.ieee
        v = await self.cluster.write_attributes({'cie_addr': ieee})
        _LOGGER.debug("%s: IAS wrote ieee: %s", self.entity_id, v[0])
        #v = await self.cluster.bind()
        #_LOGGER.debug("%s: successfuly bound '%s' cluster: %s",
        #              self.entity_id, self.cluster.name, v[0])
        v = await self.cluster.enroll_response(0, 0)
        _LOGGER.debug("%s: IAS_CIE enroll_response: %s", self.entity_id, v)
        v = await self.cluster.init_normal_op_mode()
        _LOGGER.debug("%s: IAS init normal op mode: %s", self.entity_id, v)
    except DeliveryError as ex:
        _LOGGER.error(
            "%s: couldn't configure IAS zone: %s", self.entity_id, str(ex)
        )

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Yoda-x/ha-zha-new/issues/47#issuecomment-421078520, or mute the thread https://github.com/notifications/unsubscribe-auth/AEwS9p6EYP4HTjgEReoV22C2k7OdPQ2Bks5uao8kgaJpZM4WgCew .

Adminiuga commented 6 years ago

no dice. It bails out before the "enroll_response" is sent

2018-09-13 16:35:00 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.zha_new
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.zigbee.application] sendUnicast to 0xfe34:0:0x0021
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] add command to send queue: False-True
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'2168219c541eebb259b54a25aa1593499c472ebde4e75724f3c60c84fc7f3fa2e8c4ea3984ffa8d6d5d34f6d7e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(1)/ReTx(0): b'1368a19c54b8b4b77e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'82503a7e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(2)/ReTx(0): b'2368b1ed542a1593d9944a65ab55922463f3135512316582fd1fc67e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'83401b7e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(3)/ReTx(0): b'3368b197541eebb259b54a25aa1593499cdc2eabed63f67e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'8430fc7e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.zigbee.application] sendUnicast to 0xfe34:1:0x0500
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] add command to send queue: False-True
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'3469219c541eebb658944f24ab1593499c442da5edc4659bfd366abdaa753fc8e6cd09367e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(4)/ReTx(0): b'4469a19c54b9b6127e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'8520dd7e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(5)/ReTx(0): b'5469b1ed542e14b25c954b65ab55922763f3135512316383f7c2638f567e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'8610be7e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(6)/ReTx(0): b'6469b197541eebb658944f24ab1593499cdd2dabed3de17e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'87009f7e'
2018-09-13 16:35:00 DEBUG (MainThread) [custom_components.binary_sensor.zha_new] write cie done
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(7)/ReTx(0): b'7469b58b542a214c70a4e52baa3a9f49988f227e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'8070787e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Data frame SEQ(0)/ReTx(0): b'0469b18c60d43c82f69a4a4aa755904a63b18f767e'
2018-09-13 16:35:00 DEBUG (MainThread) [bellows.uart] Sending: b'8160597e'
2018-09-13 16:35:00 INFO (MainThread) [zigpy.application] Device 0xfe34 (00:0d:6f:00:0e:af:30:29) left the network
2018-09-13 16:35:00 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=zha_new.controller, old_state=<state zha_new.controller=Run; friendly_name=Controller, no_of_entities=0, neighborCount=4, no_devices=0 @ 2018-09-13T16:35:00.002657-04:00>, new_state=<state zha_new.controller=Left 00:0d:6f:00:0e:af:30:29; friendly_name=Controller, no_of_entities=0, neighborCount=4, no_devices=0 @ 2018-09-13T16:35:00.980128-04:00>>
2018-09-13 16:35:01 DEBUG (MainThread) [bellows.zigbee.application] sendUnicast to 0xfe34:1:0x0500
2018-09-13 16:35:01 DEBUG (MainThread) [bellows.uart] add command to send queue: False-True
2018-09-13 16:35:01 DEBUG (MainThread) [bellows.uart] Sending: b'416e219c541eebb658944f24ab1593499c452caeecc5678bfd5f927e'
2018-09-13 16:35:01 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:01 DEBUG (MainThread) [bellows.uart] Data frame SEQ(1)/ReTx(0): b'156ea19c54be94157e'
2018-09-13 16:35:01 DEBUG (MainThread) [bellows.uart] Sending: b'82503a7e'
2018-09-13 16:35:05 DEBUG (MainThread) [bellows.uart] Status _send_task.done: False
2018-09-13 16:35:05 DEBUG (MainThread) [bellows.uart] Data frame SEQ(2)/ReTx(0): b'256eb197541eebb658944f24ab1592499cda2ccded04887e'
2018-09-13 16:35:05 DEBUG (MainThread) [bellows.uart] Sending: b'83401b7e'
2018-09-13 16:35:05 DEBUG (MainThread) [bellows.zigbee.application] sendunicast send_ACK failure 0xfe34:1:0x0500=EmberStatus.DELIVERY_FAILED
2018-09-13 16:35:05 DEBUG (MainThread) [custom_components.binary_sensor.zha_new] send enroll_command failed

although once it stayed a bit longer and even sent one attribute update, but still left the network. Unfortunately the logs were not preserved.

Yoda-x commented 6 years ago

yes, it looks as the sensor give up the join after 5 sec. And we not get all the commands needed send in time. Even if it is only 5-6 commands. Did you try a factory reset (10xpress)? Just to be sure there is not a problem having remains from old pairings?

Adminiuga commented 6 years ago

I did zha_new.remove service call before trying and did do factory reset on the device. Incidentally, the one time when I think I saw a device attribute report, that was after I rejoined the device without removing it from DB. I'll keep trying isolating the issue, but even if I don't do anything with the device (do not write CIE, bind or anything) it still leaves the network after the discovery. Let me know if you hear anything from NYCE as this is very strange. I don't see anything specific in SmartThings DH, but it just doesn't like zigpy.

Yoda-x commented 6 years ago

found somewhere that the sensor send a match descriptor request for the ias_zone cluster and expects to get a positive answer. As the controller currently not defines any endpoints itself and this is a supported zdo request handled by the NCP I added an endpoint for profile 0x104 with clusters 0x0020 and 0x0500. Maybe this helps. If you find some time please update zha-new (and zigpy/bellows) to the newest preview. I bumped the versions and updated the requirements. But, please verify you have a higher release. thanks

MYeager1967 commented 6 years ago

Does this get the sensor any closer to functioning? I'd love to have these working on HA. Right now, I have them on a Vera Plus and I have had to find tweaks to keep them in sync...

cancrusher commented 6 years ago

Sensor works perfect for me now. It's been connected for several minutes without a problem.

Adminiuga commented 6 years ago

same here. Yoda-x is a magician :) Nyce sensor works fine now. I still can't get Bosch sensor working, but at least now Bosch is not leaving the network. Probably just going to dump it, as it is two bulky anyway.

Yoda-x commented 6 years ago

I'm happy to hear, that this change gave some progress. @Adminiuga if you want to port this over to the upstream bellows/zigpy: The addition of the addendpoint command and creating an endpoint on the controller seem to be the fix for me. Not sure about the clusters needed on the endpoint for HA(0x104) but I added the ones, where the endpoint sends something to the controller and starts the connection. BTW: can you do me a favour and comment the _cfg command in bellows/zigpy/application.py line #61 

        await self._cfg(c.CONFIG_INDIRECT_TRANSMISSION_TIMEOUT,7700)
        LOGGER.debug("CONFIG_INDIRECT_TRANSMISSION_TIMEOUT: %s", 
                     await self._get(c.CONFIG_INDIRECT_TRANSMISSION_TIMEOUT))

My stick has a default of 3000, which means it waits just 3000ms for the answer from a sleepy enddevice. The specs says it should be > 7680. It may be problem of my usb stick, or if you have also less than 7680 this setting should go quickly to upstream. the bosch device may have some similar settings like the smartthings multi sensor. without proper information from the vendor you digging around to find some snippets of code to mimic. Did you try to set configuration reports for batter and temp. At least the smartthings DH does this.

PS: the information I found

Adminiuga commented 6 years ago

My stick has a default of 3000, which means it waits just 3000ms for the answer from a sleepy enddevice. The specs says it should be > 7680. It may be problem of my usb stick, or if you have also less than 7680 this setting should go quickly to upstream.

In my branch I'm running 'await self._cfg(c.CONFIG_INDIRECT_TRANSMISSION_TIMEOUT, 7680)', But I wasn't checking if the configuration actually take effect. BTW, does this change the timeout on HUSBZB or the "parent" router devices? ie do I need to rejoin the router if that is a provisional network parameter for any newly joined zigbee routers? I added the indirect timeout while I was troubleshooting why some of my xiaomi temp/pressure/humidity sensors go offline. So far my only conclusion was that xiaomi are very picky about their parent devices. They work fine if joined to my sinope thermostat or Osram color lights, but if I join them through 45857GE, 45856GE wall switches, Tradfri or Ledvance bulbs, then they would go offline, sometimes as quick as within 30min

Edit: on my stick default indirect tx timeout is also 3s

2018-09-21 11:59:48 DEBUG (MainThread) [bellows.zigbee.application] current CONFIG_INDIRECT_TRANSMISSION_TIMEOUT: [<EzspStatus.SUCCESS: 0>, 3000]
2018-09-21 11:59:48 DEBUG (MainThread) [bellows.zigbee.application] seting indirect tx timeout to 7680
2018-09-21 11:59:48 DEBUG (MainThread) [bellows.zigbee.application] current CONFIG_INDIRECT_TRANSMISSION_TIMEOUT: [<EzspStatus.SUCCESS: 0>, 7680]
Yoda-x commented 6 years ago

right, I had the same thing with some wall plugs. I did a capture with cc2531 and found that

the CONFIG_INDIRECT_TRANSMISSION_TIMEOUT is a local setting for your usb stick. it not gets forwarded to the routers. same for CONFIG_END_DEVICE_POLL_TIMEOUT and CONFIG_END_DEVICE_POLL_TIMEOUT_SHIFT, these are only local values. Thats why the xiaomi sensors near my controller worked fine, but these in the basement near the wall plug just worked for 30 mins.

Adminiuga commented 6 years ago

Good to know. Xiaomi sensors are nice from price standpoint, but give me so much problem :( I've also ordered cc2531 sniffer board to see what is different for cases when they stay connected and when they drop, good to know you already did it. Don't understand why they couldn't follow specifications more closely.

Question: Can Xiaomi zigbee end devices rejoin via a new parent if their old parent isn't available? Because I think one of the xiaomi motion sensor which I thought I joined to the hub ended up joined to the 45857GE switch, which got me thinking if the can migrate or not. I was under impression they go down with their parent device.

MYeager1967 commented 6 years ago

So how does one install this new code? I am running HA in a virtual environment and I'm certain that it makes a difference in the installation...

Yoda-x commented 6 years ago

How you installed my old version? Are you using git? Zigpy and bellows should update automatic if you don't use - skip-pip.

MYeager1967 commented 6 years ago

Inever managed to get it installed in the first place. 😁

Yoda-x commented 6 years ago

@Adminiuga my experience is they stay on one router. If I remember correctly they send updates without requesting an ack. I

Yoda-x commented 6 years ago

@MYeager1967 what I do is

In theory the dependencies shod be loaded automatic by the requirements in zha_new. py which points to my github

MYeager1967 commented 6 years ago

I copied the zha_new into the custom_compnent directory and it appears to have done the trick. I didn't get the -pre versions though. Was I supposed to? Haven't tested anything yet. Didn't have time today.

Yoda-x commented 6 years ago

@MYeager1967 can you fully describe what you did?

MYeager1967 commented 6 years ago

Ok, now that I have a bit of time to mess with this again, I've got the zip file copied to my .homeassistant directory. I have no idea what the "link the git" line means, but I'm going to simply copy all the files into the custom_components directory. Please get back to me and help me figure out what I'm doing wrong...

I now have the two -pre files, but it complained about dependencies for pysma being incompatible. Also, I still don't seem to be able to get the sensor to join the network. I also get the following message in the log...

WARNING (MainThread) [bellows.zigbee.application] Unexpected message send notification

Yoda-x commented 6 years ago

Hi, do you use the -skip-pip in the hass call? If yes, you don't need it anymore. if you want to be sure the dependencies get update, just start hass from the cmd line out of the venv. This may take the first time a little bit longer to start up, but it updates all dependencies. Then just stop it and start via systemctl and the pysma should be up-to-date. This log messages are normal, sometimes packets gets retransmitted.
It's difficult to help you getting only small pieces of information. Not knowing how you installed the software. what you did or having the logs. If you pulled the zip from git, parts will not work, as the zip handles symbolic links incorrect. The preferred way is to use git clone.

MYeager1967 commented 6 years ago

I installed HA manually in a virtual environment. I have no idea how to use git clone. I'm more than happy to provide any information you need. I may have to ask how to get it though. I'm getting better at this, but still not that good... I'll Google this and see what I can learn...

I have managed to figure out the git clone, checkout and preview lines. Working on "linking custom_components" part. I would think this would just be copying it over, but obviously you used the word linking for a reason...

HA is started automatically and I don't recall seeing skip pip anywhere when I edited the systemctl file, but I'll look into that as well... Update - No skip pip in startup...

I finally figured out that you basically gave me the answer above. Thanks for prodding me along. I'm working on creating the links now. More google....

I already have a custom_components folder with things in it. Is linking this to that folder going to cause a problem there?

Yoda-x commented 6 years ago

I assume you have some kind of ubuntu based linux system and you are logged in with your homeassistant user in the homeassistant directory with .homeassistant being the config dir then 

sudo ap-get install git
mkdir src
cd src
git clone https://github.com/Yoda-x/ha-zha-new.git
git checkout preview
git pull
cd ../.homeassistant
mv custom_components saved_custom_components
ln -sf ../src/ha-zha-new/custom_components custom_components

this needs to be done initially. Then you (re)start hass. For updates you do

cd src/ha-zha-new
git pull

and restart hass

I hope I added no typos. but this is the way to install it so far. Seeing that people use the zip file I need to rethink using links

MYeager1967 commented 6 years ago

I think I have much of this done already. I am running on a RPi under rasbian Stretch. Just tried the link command and definitely didn't get what I expected. :-) Will I be able to use the custom component I am currently using?

Yoda-x commented 6 years ago

Don't know what you currently use

MYeager1967 commented 6 years ago

I thought I had put it in an earlier message, but I can't find it. I'm currently using the media_player component that allows me to use tts on Alexa devices. I followed your previous message and now have a custom_components in the ls output but it's red. A restart gives me the cant find zha_new component message. I'm going to back up and do it all again to see if it's something I screwed up. Thanks again for your help...

Yoda-x commented 6 years ago

is this mediaplayer also an custom_component? just check with ls -l where the custom_components dir points to

MYeager1967 commented 6 years ago

The media_player component is/was in the custom component directory as it is a custom component as well.

I have the link as a bluish color now, inside a directory called custom_components. This is obviously wrong as best I can tell because zha_new still isn't found. the ls-l command shows it pointed to the ../src/ha-zha-new/custom_components directory. This is clearly something I'm doing wrong... I'm taking a short break. Back in a few. Going out of my mind on what seems like a simple thing....

Tried to create links to the individual files and directories and while it looked like it was good, still didn't work. Going back to square one... :-)

Yoda-x commented 6 years ago

the link should be in the .homeassistant directory replacing the orginal customs_components. But if you have another component there also, it gets complicated. Has the mediaplayer components also a services.yaml file? With the other component, you can't link the directory if you want to have both. Then please create a new empty custom_components directory and copy the files over from the src directory. As its a git clone, this shold preserve the symlinks. And also copy in the mediaplayer files (check for the services.yaml).

MYeager1967 commented 6 years ago

The other component doesn't have a services.yaml file, but it also is contained within a directory called media_player. It's pycache file is also inside the folder. I'm trying to figure out why the links I created didn't do the trick but copying them would probably be easier. Any chance that, in the future, zha_new could link into the custom_components folder as a folder itself? I'm not sure how difficult that would be, but it would possibly prevent this issue. I'll abandon my route and see if copying the files over does the trick.

I copied the files over using the cp command (which I learned preserved the symlinks) and got new errors on startup that turned out to be that the zha_new.py file contained the services.yaml text. Redid the whole git clone process and now have what I started with, including the original bellows and zigpy files ending in Y and not -pre...

Yoda-x commented 6 years ago

please check, you did the

git checkout preview

you can verify it with 

homeassistant@ha:~/src/ha-zha-new $ git branch
  dev
  master
* preview

PS: a simpler way to install it is on my todo list

MYeager1967 commented 6 years ago

I don't get the dev, just the mater and preview with the asterisk next to preview... I know this is a me thing, and I thank you for your patience... Went back to square one (again) and I think it's good now. Pip list shows both files with the -pre extension. I'm still looking at pysma being 0.2.0 but I don't know if that makes a bit of difference. Not able to pull the sensor to test this right now, but I'll get to it first chance I get. In the meantime, hopefully you'll be able to verify what pysma version I should have...

Yoda-x commented 6 years ago

pysma is not for zha, maybe a requirement of the mediaplayer. I suggest, that you remove the mediaplayer from the configuration until zha is ok. Or other way round. Just one step after each other...

MYeager1967 commented 6 years ago

I'll look into it tomorrow if I can. Only reason pysma came into play was that it gave me the messages the other day when I was trying to upgrade things manually. May not be an issue at all. Thanks again for your time and I'll let you know how it goes...

pysma has to do with SMA inverters. Seeing as I'm not using that particular option at this time, shouldn't matter...

MYeager1967 commented 6 years ago

Well, we fought with it a bit, but it's working great! Sensor paired first shot and works like a champ. Going to try one of the hing sensors next. If that goes well, and I suspect it will as it's basically the same sensor, I'll have almost everything ported over to HA. Does the battery update on these or is that something still in the works? Great job getting these working and thanks again for all your help yesterday...

Yoda-x commented 6 years ago

Cool. Thanks for your feedback.

MYeager1967 commented 6 years ago

I'm trying to find a way to track the battery now. Looks like I'm going to have to track the time between reports and throw a message after a few missed reports. Won't track battery level, but I'll at least know it's dead. The sensor reports every few hours from the look of it. I know there's work being done to actually get the battery level, but that may take time. Excellent work!

Yoda-x commented 6 years ago

The right way would be to set Attribute reporting for the battery and then check for last reporting. This may need a special device handler file to set this for the device. Battery reports are currently just ignored. This needs some extension of the code. I will add it after my vacation.