Issues with Fibaro FGBS-222-US Smart Implant adding child devices

[Irishman]

I'm attempting to get two Fibaro FGBS-222-US Smart implants to add child device "Temperature" to support external DS18B20 temperature probes. I'm using the latest Fibaro firmware version 5.1. I have triple checked and all wiring is correct. I've tried including, excluding, resetting to factory defaults and re-scanning many times but to no avail. The closest I have ever come, after numerous re-scans, is adding the child device "Temperature" on one of the Implants but that turned out to be the Internal temperature sensor. Fibaro Tech support number is a no answer busy tone. These devices would be perfect to monitor freezer and refrigerator temperatures with the external probes. Has anyone had any success using the FGBS-222-US Smart Implants?

[ChadS]

I’m having the same exact problem also. I have 3 temperature sensors connected and Homeseer doesn’t see any of them.

[Aljrob]

Wondering if anyone has had any success with this device yet? I attach a screenshot of the child devices Homeseer creates when I add the Smart Implant in the hope someone might be able to point me in the right direction.
Regards,
Aljrob

[ascotek]

Hi guys..
Numerous adding/removing do not create Temperature device on the list as shown above.
IN1/ IN2 and OUT1/OUT2 work good in mode Par 20/21 = 0/1/2/3. Did not tested in 4 & 5 values (don't need for now).
Have any one get luck with FGBS-222 to read temperature from external DS18B20?
Any advise welcome. Thank you

[RoChess]

Been communicating with HomeSeer Support on why some of my AeonLabs/Aeotec devices do not show up fully with all options exposed on a dimmer that is 7-years old with full detailed documentation available from Aeotec/AeonLabs on what each parameter does.

Reply was pretty much that they require physical access to any device that they fully whitelist and add proper support for. Now from a consumer point of views this sucks, especially with the large volume of devices added to the market, but from a developer point of view I totally understand in wanting to provide the most stable solution.

Offered to ship a large collection of my AeonLabs devices over, but their main focus right now is on HS4 which I cannot argue against either, so plan to ship them later.

Until they gain physical access to a Fibaro FGBS-222 device, HomeSeer offers full access to all Z-Wave parameters via the "Set Configuration Parameters" section, and you just select the corresponding Z-Wave parameter from drop-down box, and enter no value to 'read' existing value. Fibaro has excellent support manuals to explain what each parameter does.

https://manuals.fibaro.com/content/m...-EN-T-v1.0.pdf

Some devices get set incorrect from factory due to random testing, or in worst case when you get stuck with a returned item that was resold. Or it could be that the factory settings are not correct for your configuration. Skimming through manual I see there are a lot of conditions that could be at play that require a lot of Z-Wave parameters to be configured correctly for the Z-Wave device to report the values correctly.

Share the results, and it should help diagnose why it is not working much easier.

[joZ666]

I just added my second one of these. Got internal temp. on the new one, that's not there on my old one. But the new one doesn't create child devices for the inputs!!?
I get 11 chid dev. on the new one, 13 on the old one.
Internal Temp. is one of them , but I'm missing both inputs, voltage, notification 1 and notification 7.
Don't really care about anything other than the inputs.

[joZ666]

Answering my self here. I got the relays working when I added it unsecure through HS3.
When adding it through the z-stick it didn't work at all, log said: failed to get security scheme or verify the key.
Adding it with security through HS3 created the internal temp. sensor, but I did not get child devices for the relays.
Hope this can help others.
/joZ

[Tillsy]

Hey how did you get HomeSeer to add the (internal) temperature child on the Fibaro implant?

I had not noticed it did not add on mine, as I haven't gotten around to programming the event I was going to use that temp for, but just spotted this in my logs tonight (hence doing a search for threads):

Dec-04 8:31:09 PM

Z-Wave Error

(2) Sensor Multilevel Report for type Air_Temperature received, but the corresponding device Node ID cannot be found.(2) Node/Instance=84/-1

So the Fibaro implant IS transmitting the temperature data, but looking at all the child devices HomeSeer created it never created the temperature one and thus these errors are occurring. I remember doing a non-secure include because Fibaro gear generally works better that way (I have a lot of their double switches and dimmers all over my home).

That said, to answer this thread in itself, I DO have both outputs showing - but am only using output 2 at this point in time (have it wired inside my 2004-era non-smart ducted air-conditioner so I can trigger it on and off).
I have repeatedly re-included and still no temperature, and log still filling up with HomeSeer saying it is receiving a temp but doesn't have the child node to set.

Dec-23 5:58:10 PM

Z-Wave Error

(2) Sensor Multilevel Report for type Air_Temperature received, but the corresponding device Node ID cannot be found.(2) Node/Instance=84/-1

Dec-23 5:58:10 PM

Z-Wave Error

(2) Sensor Multilevel Report for type Air_Temperature received, but the corresponding device Node ID cannot be found.(2) Node/Instance=84/-1

[joZ666]

I have repeatedly re-included and still no temperature, and log still filling up with HomeSeer saying it is receiving a temp but doesn't have the child node to set.

Dec-23 5:58:10 PM

Z-Wave Error

(2) Sensor Multilevel Report for type Air_Temperature received, but the corresponding device Node ID cannot be found.(2) Node/Instance=84/-1

Dec-23 5:58:10 PM

Z-Wave Error

(2) Sensor Multilevel Report for type Air_Temperature received, but the corresponding device Node ID cannot be found.(2) Node/Instance=84/-1

Yepp! Same here. Rescan doesn't help & log filling up. Other than that it's an awesome device with so much possibilities. I will definitely get more of these!

/jonaZ

[ZoRaC]

Anyone been able to get the temperature child device now? I’ve connected a DHT22 and have the same problem with no temperature device.

[joZ666]

Sorry. I don't think this will be fixed anytime soon. If ever...
I did some tinkering in HS3 yesterday and I still have the temp. issue.
HS4 will probably do it right? If not, I guess it will in the future.

/joZ

[Tillsy]

Sorry. I don't think this will be fixed anytime soon. If ever...
I did some tinkering in HS3 yesterday and I still have the temp. issue.
HS4 will probably do it right? If not, I guess it will in the future.

/joZ

Thing is this isn't a HomeSeer issue - during inclusion HS adds whatever child objects the Z-Wave device advertises.

During a secure include the Fibaro implant advertises the temperature object, during a non-secure include the Fibaro implant does not advertise it.

Although HS could help but adding a temperature child for this device regardless - as once it is included the Fibaro is passing along results to the temperature object it never declared anyway, so if HS had added the object it would have somewhere to put it. Not exactly by the book but would work...........

[Tillsy]

I've become so fed up with my logs being flooded with these failures that I've excluded the Fibaro Implant and re-included as secure. Means only one output is now detected instead of two, but thankfully the one Implant I am using at the moment is inside my air-conditioner so I'm only using one anyway.... though naturally the one that does map through is not the one I had wired to, so have re-wired it to the other. All running again and no more errors flooding in all day every day. Sadly renders this product only half usable so haven't been and will continue to not buy more of these. Typical Z-Wave though, such a great standard but such an immense bag of hurt with every vendor blaming one another what a mess . Hopefully series 700 changes things as everything must be fully implemented nothing optional so should never be a case that different modes of inclusion and different devices and different controllers having different implementations.

[zguy]

Well well... That was an enlightening discussion. I can't help but wonder if this should be reported to the Z-Wave Alliance or whoever oversees the Z-Wave compatibility. After all, the promise of interoperability has always been there. I've been planning to use this device, and sadly, it doesn't work as expected. And this comes right when the design is about finished and I was ready to build the prototype.

The project is to control the 2 roof heating wires that prevent ice blockage. The enclosure where the wiring is accessible is outdoor. Because of that and the fact the smart implant is an outdoor device, the enclosure will have to be heated.

My plan was, and still is as follow:

1. use the device integrated temperature sensor and 1 output to keep the enclosure internal temperature around 5° C. This would be controlled by HS3 Pro where it would monitor that temp. sensor and switch 1 output on (when temp. is less than 3° C) or off (when temp. is more than 7° C) based on the read temp.
2. use the SP/SD input to connect a DHT22 temperature and humidity sensor
3. use the 2nd output to control relays switching power to both heating wires.

To summarize what I read above:

• both device relays get added to HS when including the device as unsecure
• device internal temp. sensor gets added to HS when including the device as secure but only 1 device relay available

Conclusion, I would need 2 devices at a minimum, 1 for the temp. sensor and one for the relays.

That leaves the inputs, SP/SD, IN1 and IN2.

Now, the questions that kill:

• Assuming I use 2 devices, 1 secure, 1 unsecure, which one would recognize the DHT22 on the SP/SD input.
• What are the "Application Status x" in the screen shot above?
• When you change the device parameters, then remove and re-include it, does that changes the HS3 child devices added?
• Which child devices gets added, or what is the difference in child devices when added as secure or non secure?
• I'm guessing not, never tried that. But can HS add a device as secure and non secure simultaneously?

[RoChess]

Worst case scenario, add the Fibaro device to a Fibaro controller (Lite is US$149 which I believe is enough) and get full control over all features, and then integrate the Fibaro controller into HomeSeer. Not ideal, but I highly doubt Fibaro cares about HomeSeer, so they will say it HomeSeer's fault, and HomeSeer points finger at Fibaro for not following standard.

It would indeed be nice if we could complain at the Z-Wave Alliance, and that Fibaro would be at risk of loosing their certification unless they make their device "All Hubs" compatible, as I'm 99% sure the fault lies with Fibaro, and I also don't like them for withholding firmware updates unless you have their controller. Z-Wave should do the same initiative that Zigbee has been doing since last year, pushed by Amazon (Alexa), Philips (HUE), IKEA (Smart Lightning), and Samsung (SmartThings) where a device has to work on all popular Zigbee hubs, and proper validation tests are available to verify before certification is allowed.

I'm stuck with dozens of Intermatic HA07 scene-controllers that are bulky, but extremely reliable and HomeSeer does not support them. However my old Vera3 controller does, and even though I had other plans for the Vera3, I'll probably re-purpose it to make those scene-controllers work within HomeSeer.

PS: My dream is still for HomeSeer to take a page out of Samsung's book and allow advanced end-users to create device configuration files ourselves that can then also be shared by end-users or by manufacturers directly. The whole GET and SET on each damn individual Z-Wave parameter is annoying, especially when you have to configure 20 dimmers with 10 parameters to adjust per dimmer, so you have to push the damn configuration button 400x, and one mistake and things act crazy that take even more time to diagnose.