Publishing the device type code to the IDE is an optional step when we certify a new device. There are two examples I can think of where we wouldn’t publish the device type as an example:
The device type was developed by a partner of ours (or by us and a partner) and they have requested that we not share their code.
The device type was submitted by a community developer and they didn’t check the box to share their code with the public.
I’m unable to get the Aeon Gen5 Recessed door sensor recognized by the hub. I followed the provided instructions at link below and did Dashboard > + > Connect New Device - the app kept spinning “Searching” even though I pressed the Zwave button on the sensor after removing battery insulator and holding it 6” from the hub. I tried resetting the device per instructions, but never saw the indication in step 8.
I also tried to connect the sensor via Dashboard > + > Open/Closed Sensors > Aeon Labs Recessed Door Sensor (Gen 5) > Connect Now - at which point the ST app crashes 100% of the time. I submitted several crash reports. Running on iPhone 6 with latest latest iOS, Hub, and ST app updates.
Another update - I was able to get the hub to find the sensor (Dashboard > + > Connect New Device), but after finding it, the mobile app showed the error that “This sensor failed to complete the network security key exchange. If you are unable to control it via SmartThings, you must remove it from your network and try again.”
I was able to remove from Z-Wave network and re-add several times, but the error about failure to exchange security keys happens 100% of the time.
Finally worked! I held it one inch away from the hub, it paired, and didn’t complain about key exchange.
However, the preference screen has an empty tile with “–” in the middle. I wonder if that is for battery. The other tiles are Open/Close, SmartApps, Preferences, and Activity.
The “official support” for the Econet vent is not completely functional as currently posted - the On/Off icon never changes, some poll() commands will not retrieve the current level, and the device does not report/acknowledge changes from the setLevel() command.
This latter one is problematic if you are try to control the vent, but want to check its current setting (switch.currentLevel) before sending a new one because the vent has to calibrate itself (cycle the damper full open/full close) before setting an actual level.
Thank you Barry. I can confirm that this does clean up the updating of the level values. I’ll get this over so that we can roll your changes into the code.