Hello,
I am a noob with Hubitat so there is a good chance that I am making a stupid mistake here. That said, here is my issue:
I am trying to control two garage doors with the implant. I have magnetic switches connected to the two inputs and have the outputs connected to the manual switch circuits on the openers.
Door 1 works fine - the input status reports and I can open and close the door with the switch (OUT-1).
However, IN-2 is connected to OUT-2, despite ‘connect IN-to-OUT’ being disabled. This means a state change in IN-2 triggers OUT-2, leading to an immediate re-opening of the garage door at closing.
I confirmed this behavior in benchtop testing with a second Smart implant and a couple of LEDs - IN-1/OUT-1 are independent, but IN-2/OUT-2 are linked.
I am running version 1.7.6, so as far as I am aware I should be up-to-date.
Any suggestions how to deal with this are very much appreciated!
So you set both " Input/Output 1 - Local Device Protection? *" and " Input/Output 2 - Local Device Protection? *" to 2?
Could you "Enable debug logging", "Save preferences", "Check Config" and after a minute or so copy the debug log that has been generated and post it here. Maybe also trigger both doors and also copy the generated log here.
First of all, thanks for getting back - very much appreciated!
As for the issue, I figured it out. I believe what happened is I somehow managed to have the child processes not updated after switching to your driver.
Not sure how I fixed it, but after some switching around and multiple re-configurations everything is working now!
As I said, new to the HUBITAT….
Btw, if I use the ‘donate’ button in package manager, does the PayPal transfer actually end up with you? I’d like to buy you a beer
A little experience I acquired with the DS18B20 sensors and the Fibraro FBGS-222 Implant. I have an implant that has 4 sensors on it working well for several months (using christie999’s driver), until it came time to remove one the sensors that was embedded in my pool filter for winter storage. This caused the implant to lockup after a period, and then would not re-establish comms with the remaining 3 sensors. So I decided to try to replacing the “offline” sensor with a temporary unit. Well that worked, partially, allowing the 3 remaining sensors to re-establish comms with the implant. However, the sensors I had procured had compatibility issues with the implant, and generated “Need to handle this cmd.notificationType: 9” hardware faults. I read the other community notes on the fault and saw where others would still get readings even though they got frequent fault messages. I found I got reading too, but they were significantly delayed. Often only updating every 10 to 15 mins, instead of the normal 60 secs or less.
Well, I purchased a second set of sensors on Amazon, from a different brand. Same thing, more faults. So finally, I went back and bought more of the original brand, that worked with the first batch. They WORKED perfectly! A few comments though…
When replacing a sensor, the FBGS-222 needs to be power cycled to recognize the change.
The sensors may get shuffled, relative to their assigned tags in device. I worked around this by mapping them to virtual devices with a rule that runs when any temperature changes. That isolates all of the references and keeps them from breaking other rules, dashboards, etc.
Did NOT have to exclude/include the implant to get it to recognize the sensors.
The brands that did work were TWTADE (which has a longer 3m cable) and Otomatico (the pool sensor that has a ½” NPT fitting).
The ones that produced the Type 9 errors were Gikfun and BOJACK.
I saw nothing in the comments or specifications that would indicate anyone would be better or worse. In fact, the Gikfun had a lot of good ratings for working well with Arduino.
I saw the Fibaro community entry christie999 referenced. The ones that did not work, must have been counterfeit clones.
Overall cable length does not seem to be a big issue. I have at least 5m to a junction box and 4 probes with 3m each.
Curious if anyone has had issues with the Smart Implant where it stops reporting the external temperature. I added the smart implant and it has a DHT22 sensor attached. It will report the temperature every 5 minutes initially, but it will eventually stop reporting.
My 5 external temps stopped again this morning. Just noticed logs flooded with "Need to handle this cmd.notificationType: 9" over the last few days. Suspect the cold weather here (<20F) may have caused the sensors, wires to "fail". Rebooted the implant and they all ready 32F now. Hopefully all comes back when it warms up (in July ). At least the "Type: 9" errors stopped after the implant reboot
How long did it work for? Does the internal temperature still work? Are you getting the "Type: 9" error in your logs?
I get those type9 erros every now and again.
Interesting there was a bit of a cold snap here, -10/12 C, a few days ago and I got 2 warnings each day.
It's been back to 0 C the last 2 days and no log entries.
Are you getting any actual readings? 32F/0C seems to be the default for no reading.
If the readings aren't changing, the sensors have failed. Once that happens the implant does not appear to self recover. Either a power cycle or even re-install may be required. I'm still waiting for things to warm up here to see if another power cycle will restore my temperatures.
I haven't looked in a while as it's my pool temp
I see it has reported down to 0.3 C for the last 2 days properly but no events since dec 23. We did have a cold snap for a week or so but Xmas nice and rainy so no negative temps there.
I'll keep an eye on it now to see what happens at -x C.
No events, likely means it has stopped responding, and maybe locked up. Is the internal temp updating (new events)? If not the implant has locked up. I found that would happen over time if too many errors came in. If it's just your pool temp, you can obviously wait until it warms up again.
I setup a deadman timer, that monitors the internal temperature for changes. If it goes more than 2-4 hours without changing I likely have a lockup. When it locks up, nothing responds, including the outputs.
I have an FGBS-222 with DHT22 in my attic. It occasionally goes south (every 6 months or so), and reports (exactly) 0 degrees C (or doesnt report, ands a default as noted elsewhere) Nothing but a hard power cycle will bring it back.
But over the last week (with cold spell here, temps below 30 degrees F), things have gone south. Even though Im configured for 20 minute reports and "1 degree" temperature change reports, the fgbs-222 is reporting like mad; multiple reports and/or temp/humidity changes per minute (even for 0.1 degree changes).
I dont know if the its the DHT22 or the FGBS thats gone south, or cant take the the temps. I've tried power cycling but its to no avail. The traffic has been high enough to get flagged in the logs with the 'device xx excessive load on hub' (sic) .
I'm guessing we are pushing these Dallas 1-wire sensors a little to much. 5V devices can't be that hardy for longer applications. Good discussion of the limitations at Guidelines for Reliable Long Line 1-Wire Networks | Analog Devices.
Although my sensors are spec'd for -55C, suspect that is for optimal network configurations. Also, doubt the Implant has a very robust implementation. Guessing those "Type: 9" errors are resulting in memory leaks that finally lock-up the whole Implant. Had hopes for these monitoring outdoor temps, but might just be 3 season devices here in the north. Hoping they come back when it does warm up.
The sad part is that these sensors can't usually be replaced willy nilly. They're in locations that require getting to, setting up, etc, etc. That's kind of why I decommissioned it on my heating buffer tank. It was just a like to have kind of thing anyway.
Yeah, the Type:9 errors started up soon after my last post and ran for about a half hour before stopping around 8:38AM. Restarted around 4:30PM and went all night. Temperature readings stopped updating around 4:30AM. I'm pretty sure the Implant is not very robust in handling the errors. Anyway, it was installed mainly for the pool temperature during the summer, when it seems to work OK with normal temperatures.
Purchased a new Implant, as the old one ceased responding. Excluded the old one, included the new one, changed driver, configured, and re-installed to clean-up child devices. Now get hub load errors when ever a temperature input is processed. Any suggestions?
One measurement report every 30 seconds should not lead to an overload. From reading other threads about "Excessive Hub Load", I see that it is not necessarily related to the implant itself, for instance:
). At least the "Type: 9" errors stopped after the implant reboot
