FIBARO US Wall Plug w/USB Second Channel Issues

Devices & Integrations
1

Anyone having issues with this device or know what would cause the second channel to go offline and cause the following errors in ST IDE logs? The power reporting was delayed substantially for a long time and now it’s stopped reporting altogether, but USB outlet still has power and works fine - just doesn’t report power.

Here’s the device in question:

Live Logging:

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:50 PM: warn chanell1

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:50 PM: warn Bedroom Air Conditioner - MeterReport received, value: 2085.28 scale: 0 ep: null

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:50 PM: debug Bedroom Air Conditioner - Parsed: MeterReport(scale2: false, scale: 0, rateType: 1, precision: 2, meterValue: [0, 3, 46, 144], deltaTime: 0, meterType: 1, size: 4, scaledPreviousMeterValue: 0.00, scaledMeterValue: 2085.28, previousMeterValue: [0, 0, 0, 0])

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:50 PM: debug Bedroom Air Conditioner - Parsing: zw device: 13, command: 3202, payload: 21 44 00 03 2E 90 00 00 00 00 00 00

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:49 PM: warn chanell1

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:49 PM: warn Bedroom Air Conditioner - MeterReport received, value: 0.0 scale: 2 ep: null

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:49 PM: debug Bedroom Air Conditioner - Parsed: MeterReport(scale2: false, scale: 2, rateType: 1, precision: 1, meterValue: [0, 0], deltaTime: 0, meterType: 1, size: 2, scaledPreviousMeterValue: 0.0, scaledMeterValue: 0.0, previousMeterValue: [0, 0])

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:49 PM: debug Bedroom Air Conditioner - Parsing: zw device: 13, command: 3202, payload: 21 32 00 00 00 00 00 00

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:18 PM: warn chanell1

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:18 PM: warn Bedroom Air Conditioner - MeterReport received, value: 0.0 scale: 2 ep: null

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:18 PM: debug Bedroom Air Conditioner - Parsed: MeterReport(scale2: false, scale: 2, rateType: 1, precision: 1, meterValue: [0, 0], deltaTime: 0, meterType: 1, size: 2, scaledPreviousMeterValue: 0.0, scaledMeterValue: 0.0, previousMeterValue: [0, 0])

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:19:18 PM: debug Bedroom Air Conditioner - Parsing: zw device: 13, command: 3202, payload: 21 32 00 00 00 00 00 00

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:18:48 PM: warn chanell1

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:18:48 PM: warn Bedroom Air Conditioner - MeterReport received, value: 2085.28 scale: 0 ep: null

e0f38e65-061b-4ab8-8c69-507ebde147e5 5:18:48 PM: debug Bedroom Air Conditioner - Parsed: MeterReport(scale2: false, scale: 0, rateType: 1, precision: 2, meterValue: [0, 3, 46, 144], deltaTime: 0, meterType: 1, size: 4, scaledPreviousMeterValue: 0.00, scaledMeterValue: 2085.28, previousMeterValue: [0, 0, 0, 0])

2

Generally everyone is having issues with fibaro devices. It is there fault for not providing support to fix their integration. This is why i ditched them.

3

That simply not true. Mine all work perfectly fine and have done for many months. The only issues I have had are when ST make changes the platform.

@GRClark What DTH are you using? I am using Z-Wave Metering Switch for mine and have no issues, although it is the earlier one without the USB interface. Do you need power monitoring for the USB port?

1 Like
4

I don’t have any plugs. I am using switch 2s. But from what i gathered, most fibaro devices don’t work well with smartthings and probably never will.

5

Not the case at all. I have 11 x Dimmer 2, 8 x Doubles Switch 2, 3 Door sensors, 2 smoke detectors, 2 outlets and 1 x Binary Sensor. All working flawlessly today and very few issues over the past 3-4 years of using them.

1 Like
6

That made my day, thank you! :rofl:

1 Like
7

Flawlesly? Come on i have had these for quite some time and never worked flawlessly. Double switches have their 2 second channel turn on or off with a lot of latency. Smartthings status on Fibaro switches is usually wrong. The devices do not work locally. Changing the dth to the generic z-wave one works locally but is still slow and status takes forever to stop spinning. Not to mention that trying to run multiple devices within an automation or scene (z-wave) takes for ever. Never had an issue with my door sensor. As for the rest. I will never buy a fibaro product again!

I also confronted Fibaro on multiple occasions on both fibaro support, twitter and smartthings forum and they always respond that they cannot provide support or make new device handlers for the new app.

There are also many posts in the forum with many people having issues with fibaro devices. I can find some if you like.

1 Like
8

What can I say? My experience with the modules has been good. The new app sucks so most of the time I either use Apple Home app or Alexa control. Both are almost always faster that the ST app.

Anyway, YMMV

9

Fibaro devices are zwave certified and work fine out of the box with almost all certified zwave hubs. They do have a lot of advanced features, but as long as the platform provides support for setting associations, managing multi endpoint devices, and managing central scenes, everything works fine.

SmartThings does none of these. :disappointed_relieved: Instead, it puts its own abstraction layer (like child devices) over the top of the independent third party protocol, and that layer doesn’t support all of the protocol features.

The result is a requirement for custom code that no other platform has and an inability to support all features of some certified devices. :scream:

That’s not the fault of the device manufacturers.

Case in point: the Aeotec Wallmote quad is designed to support 16 scene options—and it does, with most zwave hubs. With SmartThings, you only get 8, even with a manufacturer-provided DTH.

It’s incredibly annoying, but it’s because of the ST architecture.

The whole point of zwave from the beginning was that certified devices would be interoperable without requiring custom code. ST regularly breaks that promise, and I can’t blame manufacturers who have thrown up their hands and decided not to take on the additional costs and support headaches of dealing with ST idiosyncrasies.

By all means, if you want to stop buying a specific manufacturer’s certified zwave devices because they have chosen not to provide ST-specific support, do so. That may well make the most sense for many individual customers.

My own hope, although it’s just a hope, no one has said this will be true, is that the Aeotec partnership Will mean that within a year or two the smartthings zwave implementation will come into line with the third-party protocol, and more devices, particularly those using central scenes, direct associations, and multiple endpoints, will just work out of the box with stock DTHs. Because it’s going to be pretty embarrassing if Aeotec devices work better with everybody else’s hub except their own. :wink: but we will see.

10

@JDRoberts May i ask how do you know this?

11

It’s the whole reason DTHs exist in the first place. You can see the architecture and you can see it in all their published documentation. And you can see what’s missing from the UI.

image
image792×612 30.5 KB

There’s no way to set up an association or an automation using a central scene number without creating custom code.

The parent/child construct is not part of the zwave specification. It’s part of the smartthings overlay architecture.

So there’s no secret about any of this. It’s the way the platform works.

Just research how to respond to a central scene device on any certified zwave hub.

12

Thanks for the info! So this is why child devices cannot be set to local!

Is this the case with zigbee devices?

13

Yes, it’s the same issue. As a multi protocol platform, smartthings decided to add their own abstraction layer above the actual protocol communications. That’s what a DTH is.

On the Zigbee side, the biggest impact that I’ve seen has been again on multi endpoint devices which are, again, in the smartthings architecture implemented with parent/child devices when that is not a zigbee concept.

All the multi button devices which worked with classic and then did not work with the current V3 app broke because of the smartthings architecture. Not because of the underlying third-party protocols. And the fix was yet again more SmartThings-specific custom code. :thinking:

14

Realy? So this where most of our troubles come from… so a major change will need to be done in order for a proper protocol implementation. Meaning multi-entpoint devices most probably will never be set to local.

I have been using home assistant for 2 years now, but this got me thinking if it is time to move everything over.

Was there some reasoning why they decided to go with this approach?

15

They’ve never said for sure, but I assume it comes from the original goal of making everything work without the end-user having to know about the protocols in use.

This was evidenced from the very early days when they would talk about Z wave having clusters, which of course it doesn’t. Zigbee has clusters. But they tried to fold everything into one uniform Architecture.

As for what we’ll see in the future, I don’t think there’s any predicting until they tell us more about how hub connected devices will work with the new platform. it could be much better than what we have today, they could be highly similar, it could be limited. We will just have to wait and see.

1 Like
16

Got it off @TheSmartestHouse website.

image