Fibaro wallplug FGWP102 not reporting

found other old topics with the same kind of question but no solution yet.

I’ve got two Fibaro FGWP102 wallplugs, expecting them to send notifications when there is a significant change in power consuming. They both do not send any power reports, but they do reply to server polling, which I set to every 2 hours. The parameters (for testing):
10 - high prio power report: 10
11 - standard power report: 1 (had 10, 15 etc too but no change in behaviour)
12 - power reporting interval: 30
13 - energy consumption power report: 10
I added an Item to the channel power_watts. This item gets updated correctly every 2 hours (on server poll), but not every power change. E.g. If I connect/disconnect my laptop, I see no activity whatsoever in the logs, but after the 2h poll, the watts change is reported correctly.

Strange thing: I’m migrating from Indigo domotics server. If I go back to Indigo (same machine/controller), I do get power reports every few seconds from these devices (e.g. 23.1 -> 24.3 power change), and I can correctly identify the time I connect/disconnect my laptop within a few seconds due to plug initiated power reports. I’ve suspected the plugs to not work correctly, but then I cannot explain why they work on Indigo? Anyone knows where/what to check? I’ve tried updating to openhab3, but same behaviour as openhab2.

thanks!

Welcome.

I do not see them listed in the community maintained device database for the binding.

In the zwave directory under userdata openHAB should have created an xml; file with information from the device. Please post it here so I can verify that the binding has the prope rinformaiton about the device.

whoops, typo, FGWP102. corrected it in title + text.

1 Like

OK that narrows it down to 2 possibilities, depending on the firmware version.

One database entry was last updated 3 months ago but the other one was updated and is currently only available in a snapshot release of the binding.

What version of openHAB are you running?

I’ve tried 2.5.10 and 3.0.0, both the same. Currently on:
2.5.0 openHAB Core :: Bundles :: Core
2.5.10 openHAB Add-ons :: Bundles :: ZWave Binding

device properties:
manufacturerRef 0602:1001,0602:1003
modelId FGWP102
versionMin 3.2
zwave_deviceid 4099
zwave_devicetype 1538

OK, whether you choose 2.5.10 or 3.0.0 you need to manually install a snapshot version of the binding. Here is a script for OH2 that may work with OH3. It uninstalls the current Z-Wave binding and in stalls a newer snapshot version. basically the only change is the database in the file.

Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community

After the binding is installed, you need to delete the device Thing from OH (do not exclude from the network) and then rediscover & add to get the latest binding settings.

The README file of the script has manual installation instructions.

I’ve run the script, with some adjustments (mainly grep works different on macOS). It does not finish successfully (timeout after 2 mins) but it did install a new version of the zwave addon:

2.5.11 openHAB Add-ons :: Bundles :: ZWave Binding

Removed the Thing and re-added it, but there is no difference. Plug in or out the laptop does not show any reports from the plug, only every 30 minutes (I’ve increased the polling interval).

On Indigo server, within 1 second of unplugging / replugging the laptop shows power usage changes to 0 watts and back to 45 watts when replugging. In Indigo the device is automatically set to a polling interval named “Only when Activity Detected”:

The top item on the list, Only When Activity Detected , is a great optimization - some devices send out a message whenever they change - they don’t actually send the necessary information for Indigo to automatically update state, but it is enough to bump the device to the top of the poll list so that the status update will occur much more quickly. And it keeps us from having to poll the device at regular intervals because we can just poll it when we see this specific message.

This could mean the device does not actually send reports as it is configured by default, but it does send some other zwave packet that triggers a poll from Indigo. Is there some similar setting in openhab? can I turn on extra logging to see if there is any zwave activity that is not logged by default in the log files?

OK the script was mainly developed for Linux.
this is from Linux but what is the output of
openhab-cli console 'bundle:list | grep -i zwave'
The password would be habopen. That should show the version of the installed binding.

I pasted that in my previous post:

That means iot did not update. The manually installed one should have a 2.5.12xxx number .
The binding should be here.
https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/job/openHAB2.5.x-ZWave/lastSuccessfulBuild/artifact/target/org.openhab.binding.zwave-2.5.12-SNAPSHOT.jar

ok, well it did something, as you can see before I had 2.5.10 and after the script 2.5.11.

I’ve dropped the snapshot in addons, and manually stopped 2.5.11:

282 │ Resolved │  80 │ 2.5.11                  │ openHAB Add-ons :: Bundles :: ZWave Binding
283 │ Active   │  80 │ 2.5.12.202101030439     │ openHAB Add-ons :: Bundles :: ZWave Binding

then I deleted and re-added the thing. Still no difference: no logging whatsover of me un- or replugging the laptop.

The old binding must be uninstalled from OH.

Ok I’ve uninstalled 2.5.11 and restarted the snapshot bundle. No change in the wallplug behaviour. Additionally, most battery powered zwave devices are now stuck in “Node initializing: REQUEST_NIF” state, even though events generated by them are handled correctly.

The console lists it as resolved. That means it is not uninstalled. I am not expert enough to instruct on uninstalling from the console.

I removed it after your previus post with
feature:uninstall <featureid>
this is now the output:
list | grep -i zwave
283 │ Active │ 80 │ 2.5.12.202101030439 │ openHAB Add-ons :: Bundles :: ZWave Binding

I got same device same firmware everything works fine.

If to much nif (or dead devices) your zwack Traffic could be to high-> wait until nif is gone, kill dead devices from stick

Second option: did you tried to reinitialize device from openHAB? This will cause get new xml sometimes solves such issues

zwave/network congestion was not an issue with 2.5.10/2.5.11. Some devices are still in “Node initializing: REQUEST_NIF” state after 4 hours, while they are working correctly (means they send events which are reacted on in rules). Seems an update issue with the state, not a real issue with messages.

I reinitialized the device from openHAB, I got a new xml file for the node in the zwave directory, but still nothing.

@JensH: Do you get updates immediately when there is significant change in the meter_watts channel? did you change any parameters, or was it plug and play? Because the default parameters seem to suggest that they should do that. I started experimenting with them because it did not work with the defaults, but have not found a combination that does.

NIF needs some time until device waked up some times. I have some wake up every week, sometimes needs 2-3 weeks without nightly heal to get rid of NIF. You can fasten by wake up manually.

I got Updates same moment. Because I don’t remember the screenshot of power meter parameters of V3.2 device:

Thanks. My settings are very similar, except I cannot get param 13 and 14 to “select a value”, they display a default value (10 and 3600) which cannot be deleted (I think this is a display thing and they are actually empty, you probably have a slightly different version of openHAB). I tried a lot of things, like rebooting the server, excluded the device from the controller, reset and re-include, reconnected the Item. No change. If I stop openhab and start Indigo, I get all the events I expect. Can you tell me which channel you connected the Item to, and maybe show the Item configuration? I think I got this right, because the poll updates the right Item, but maybe I did something wrong there?

If it updates manual refeshs, the items are o.k.

And if you allready did a refresh, I have no further ID, except updating openhab to newer version (mine is 2.5.11)