@christi999, thank you so much for the updated drivers! I just installed my first smart implant yesterday and thoroughly enjoyed reverse-engineering the old alarm system in our new home and discovering all the existing door and window sensors.
Even though I set up the drivers as directed, the digital inputs didn't register closed or open until I actually closed and opened the doors for the first time. Due to my ignorance, I thought something was wrong because I didn't understand why the digital inputs didn't show anything at all, and so I removed and reset the implant, uninstalled and reinstalled the drivers, and configured everything all over again. Then I started opening and closing the connected doors while having all the device status pages and the log open in different browser tabs on my phone just to see what was happening. LOL! It's working beautifully now. As an aside, my door sensors had to be set to "Normally open alarm input (Notification)".
I think it would be helpful for others if it's noted in the driver installation instructions (preferably in the GitHub readme) to indicate that once you've set up the device and the attached door/window sensors, you may have to open and close those attached doors/windows before the digital child devices will register status.
Again, thank you so much for all your hard work to make this available to us!!
@luniel, glad it works. As you suggested, I will add some comments in the readme file. As for the normally open/closed, I had planned to check that but it fell through the cracks. Changing it now if necessary would probably create more problem than it is worth for people already using it, if they ever updated the driver.
I believe there is a bug with the smart implants that I need to verify. I ran into it while testing today. While browsing their forums I also saw mention of this.
When the power is reset on the device, the inputs get triggered. So if you are using it for an alarm if the power goes out or flickers just enough, the alarm will start going off. Equally as dangerous if using to control a garage door. I'll try and investigate more tomorrow.
But so far, I'm not really happy with how the smart implant works. Not really doing features it was advertised to do.
I couldn't replicate this on my system. Upon power on (after a power cycle or power glitch), all I get from the implant are 2 switch binary reports indicating the current state of the 2 outputs. I never got any notification message that would indicate an alarm was triggered, I tried both NO and NC.
As far as your other post in Implant Support, I get the same result, output 2 is linked to input 2 even with local protection enabled, so that seem to be a bug in the implant firmware. I use input 2 as analog so I never noticed it before.
Glad you were able to replicate the output issue. But also pissed as it's something I won't be able to get fixed because Fibaro doesn't release firmware updates for OTA. You need their Home Center hubs for updates. I guess I'll set it up as analog inputs instead to work around it.
I jumped on a couple of Smart Implants as soon as I was able to, but I must agree, I was a bit disappointed. To this day, my two implants haven't left my breadboard. Have you already read about the MonaLisa board (aka Thingshield)? It could be a good alternative for your needs. And even though it can be used as an Arduino shield, it can also do a fair bit as a standalone device. Here's a snippet from the docs:
"The board has 2 digital inputs, 4 digital outputs (with corresponding LEDs), and 4 analog inputs. It thus can be used standalone as a simple smart device"
That is very interesting. But my fallback plan would be to run another wire from the garage doors to the alarm panel which already has Hubitat integration. I won't set those contacts to alert on the alarm itself. But I can monitor them with Hubitat. Then I'll use the implant to trigger the doors to open and close. So it wouldn't be a total waste.
Thanks for the driver. It's working for the most part for me. Are you interested in enhancing the driver functionality? I need temperature offsets for the external sensors so I can calibrate them before deployment. For instance, my two probes are in the same glass of water and one is + .6° as compared to the other unit. I would think a +/- 0.1° to 5.0° Offset range would suffice. Is it possible to build this into the driver?
Hi Travis, I don't mind adding small things like this if it can help. I posted version 1.0 on Github and tested only with the internal sensor. The range is +/- 7 degrees (float), same as my goControl thermostat...
Chris
Fantastic! That worked really well. I tested with a negative offset and it worked immediately. I did notice that the driver information on the parent still shows .8 as the version. I think that's because you seem to be missing the refresh for the parent itself. Just using configuration button alone didn't cut it. Thanks so much Chris for the amazing response and work on this.
Yeah, I have all the new settings and they are working...however the State Variables still shows "driverVersion 0.8" for me. BTW, is "Child Refresh" on the Parent supposed to be the same as hitting the "Refresh" in the Child Devices? I'm not clear on that. If it is, it doesn't refresh them but when you go to the actual Child Device and hit Refresh it works there.
Refresh only works for the child devices where the implant supports it. I included it in the parent because without it I couldn't get the child ones to work, I never went back to try and fix it. I will look into the driver version thing.
@daweeze, version 1.3 is posted. It should take care of the version not showing up correctly and I also removed the parent commands that were really child device's. You MIGHT have to remove/re-add the device because of the way I changed the state variables handling.
Thanks Chris. I did remove/re-add the device but didn't test to see if I HAD to since I have no rules associated with it yet. Version updated correctly. Only configuration is on screen for the parent device and everything working that I have tested so far! Not sure if you have participated yet but any chance you can put this in HPM so users can receive automatic updates?
Thanks for the consideration! It can provide automatic updates but I suspect most don't use it. Instead, it at least lets you know that there's an update available and automates the install if you choose to update it.
It is not a bug in the firmware. When I initially implemented the protection class in the driver, I just sent the protection command to the base node of the implant. However, I noticed tonight that endpoints 5 and 6 (the switches) also support the protection command class. Sending individual commands to each endpoint control individually in/out1 and in/out2. I guess sending it to the base node only affect in/out1.
