Support for HA version of NYCE sensors?
Closed this issue · 68 comments
Any chance this will allow the use of NYCE tilt and hinge sensors? They are the HA versions and not the Iris ones...
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.
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.
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
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
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
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...
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 throughpip3 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:
- yellow/red/yellow -- while joining
- joins than leaves
- 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"?
- ok, if you use git+http: you need git, I just used the URL (without git+) as it is.
- 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...
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).
ok, next try. please get a fresh copy of the zha_new from preview
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)
)
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.
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?
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.
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
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...
Sensor works perfect for me now. It's been connected for several minutes without a problem.
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.
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
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]
right, I had the same thing with some wall plugs. I did a capture with cc2531 and found that
- for the wall plug the xiaomi keepalive time was to long. The device timed out of the neighbour table, then the xiaomi send its keepalive and the wall plug send a disconnect to the xiaomi. Other devices do then a rejoin. not the xiaomi, it just stays disconnected.
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.
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.
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...
How you installed my old version? Are you using git?
Zigpy and bellows should update automatic if you don't use - skip-pip.
Inever managed to get it installed in the first place. 😁
@Adminiuga my experience is they stay on one router. If I remember correctly they send updates without requesting an ack.
I
@MYeager1967 what I do is
- clone the zha_new repo under the homeassistant user directory as homeasstant user
- git checkout preview
- git pull
- link the git directory custom_component into conf directory as custom_components
- switch to the venv directory and activate it
- start Hass
- run pip list to see if bellows and Zigpy gets updated
In theory the dependencies shod be loaded automatic by the requirements in zha_new. py which points to my github
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.
@MYeager1967 can you fully describe what you did?
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
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.
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?
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
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?
Don't know what you currently use
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...
is this mediaplayer also an custom_component? just check with ls -l where the custom_components dir points to
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... :-)
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).
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...
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
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...
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...
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...
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...
Cool. Thanks for your feedback.
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!
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.
Great! I wasn't sure what was involved as I haven't even had time to look at your code and begin to try to digest how it does what it does. I'm fairly competent with Python, but I'm not really an object oriented programmer. Having actual battery reporting would be great but seeing as it isn't currently there, I was more interested in pursuing a method of knowing when it died. Always better to have it work properly, but I'm not in a position to accomplish that. Once again, great work on this. I have two hinge sensors and the tilt sensor and they are working flawlessly. Much more reliable than they were on the Vera and it no longer takes a minute for them to update into HA. Enjoy your vacation!!!
I added the battery cluster and temperature cluster to the binary_sensors.
both update the "last seen" attribute.
Battery can report "Battery_Voltage" and "battery level", please update the preview branch of zha_new.
If it not works please provide the log message for the battery message you see.
Thanks for being a beta tester, I have no option to really test it.
I started python programming at the beginning of this year. I would not call me a python programmer ;-)
Just updated the git pull and copied over the changed file. Will let you know when the sensors update again. Right now I have this for information:
last seen: 2018-10-12T16:00:27.058577-04:00
rssi: -67
path: direct
manufacturer: NYCE
SUPERVISION_REPORTS: 1
BATTERY_DEF: 0
model: 3010
ALARM1: 0
TEST: 0
TAMPER: 0
last detection: 2018-10-12T16:00:27.059015-04:00
nwk: 34259
lqi: 255
friendly_name: Front Door Sensor
TROUBLE: 0
BATTERY: 0
AC_MAINS: 0
ALARM2: 0
RESTORE_REPORTS: 1
And it updated right after I submitted the comment...
this means you see some battery stats? Cool. First time a change works without fixing 10 typos afterwards 😃
I'm not sure what was there before I updated it other than the AC_MAINS line. There's a lot of data here that I don't know what it's for. Battery 0 doesn't look too good though...
nothing to worry about, BATTERY:0 means your Battery is ok, 1 means low. All the UPPER_CASE attribtutes come from the IAS (0x0500) cluster and not the power (0x0002) cluster. If you don't see a Battery_voltage or battery_level attribute. You not receive battery updates.
How often should the battery updates come in? As of now, I still have nothing for voltage or level. I haven't activated any logging other than what HA starts out with, so if you need any logs, you'll have to point me to what you need. Great work so far. For only having been using Python for a short time, you're way ahead of me. I just tinker for various home control projects, not into the object oriented style at all...
not sure if they come automatic. the smartthings device handler sets them.
you can try to add this to your zha config and then repair the device, please replace the mac address with you device mac:
zha_new:
device_config:
"00:15:8d:00:01:14:82:aa-1":
type: binary_sensor
config_report:
- [0x0001, 0x0020, 60, 3600, 5]
- [0x0001, 0x0021, 60, 3600, 5]
This requests the attribute reports for battery voltage and remaining percentage from the device, if available.
you find the mac address of the sensor in the zigbee.db, the "-1" is for the endpoint.
otherwise I can create a device file, which you can copy to custom_components/device
I'll look into adding this to the config file. Why would you need to pair the device again? Wouldn't adding the command kick it off on the next restart? How would the device file act any different unless it would automatically pick up multiple sensors?
Attribute reporting request are only written to the sensor during pairing. After pairing the battery powered sensor goes to sleep and you don't know when it wakes up. So if you want to tell the device to send attribute reports you have to re-pair it.
Configuration.yaml vs device files: in the configation file you modify the device based on it's hw address and endpoint ID. This includes devices type, clusters to use, and also the attribute reporting.
The device handler file can do the same and much more based on the model name (3010). It is a more generic approach. No need to configure every device in the config. My code discovers the model name and checks if a matching file is available and configures all your nyce 3010 devices. If you have 3014 devices you can also easily reuse the 3010 file
The only thing at a restart, is that you don't see a status, until the sensor sends an update. As it is now.
In that case, device files are probably the way to go. I have both 3010 and 3014 devices.
Ok, I got around to removing and repairing my garage door sensor with the changes to the config file. We shall see if it changes anything. :-)
Ok, here we are, a week later, and I have no additional data for the device having anything to do with battery. At least removing and repairing on these devices under Home Assistant doesn't break everything as it did on my previous controller. Any chance you'd want to take on adding support for the last device I have on Vera?
I lost my crystal ball. What you have left?Just open another ticket, provide some logs and the data from zigbee.db and lets see ...
The last device I have tied to Vera is a Z-Wave device. It's a ZWN-SC7 scene controller. I asked as more of a joke as I've been trying to find support for it for months and I've found nothing. As for the rest of the last message, I added the lines to the zhanew config to configure battery reports on the 3014 tilt sensor device. Doesn't look as though it worked as I still have no additional battery data. Honestly though, it's not a massive issue as these things have been rock solid under your code and they were hit and miss at best on the Vera...
no worries. homeassistant is a serious topic 😉.
Did you tried to open a ticket within github for homeassistant/zwave to add the device? I think they guys developing z-wave will catch it up, same way I did.
I wasn't aware that there was a github for it. I guess I should have known as there seems to be one for everything these days. I'll search for it and see if I can find it. I still have the scene controller on Vera and a dimmer (because I'm using Vera for my Alexa integration at the moment). I'm ok with this arrangement though as the Vera is actually stable when there isn't much on it...
closing this ticket as it seems ok now,