[SOLVED] [Fibaro Smoke Sensor] Problem with temperature monitoring intervals

Add-ons Bindings
#1

Hello,

First I’d like to mention that I’m new here and this is my first post :slight_smile: So hi guys, and thanks for all the work that brought us OpenHAB. I switched to it from Fibaro HCL and I LOVE IT! :slight_smile:

I have however problem with temperature readings that I get from
FGSS001 (dbReference 134)
FGSD002 (dbReference 129)
FGDS002 (dbReference 878)

Sensor 134 posts temperature quite OK, every few minutes when there’s a change, but other sensors - 129 and 878 do it every few hours and this doesn’t change no matter what I set in 20: Temperature report interval or 21: Temperature report hysteresis. They usually send temperature change only with Wakeup interval which for 129 is no less than 21600 (6 hours!). Weirdly enough other sensors can be set lower than that.
Please help :slight_smile: My wife is moaning all the time that “Fibaro was better because I knew temperatures right away” and it’s driving me nuts :wink:

Some system info:
Raspberry Pi 3B+
openHAB 2.4 stable
zwave binding installed in PaperUI
Aeotec Z-Stick Gen5

Thanks!
randarth

SOLUTION:
**As pointed by @robmac my problem was that Association Group 1: Device Status was not set. **
After selecting ‘Controller’ and waking up the devices to confirm change everything started to work fine.

#2

Hello :wave: and welcome to the openHAB community :heart:

How to ask a good question / Help Us Help You

Many people here are happy to help you, but I am lazy!
We get so many questions every day, you should read the above linked post for future topics created :slight_smile:

As said, lazy af :zzz: I would love to help but I don’t want to figure out what a FGSS00* dbReference *** is
I would much more prefer your telling us what binding you used, which docs you read, did you follow a tutorial? yada yada yada

So we don’t have to assume so much stuff which makes it very difficult.

1 Like
#3

Thanks for reply :slightly_smiling_face:
Well, I think that all the things you ask are actually in my post.
Model names along with referenceDB id’s are there to provide you with precise types of devices I’m having problems with. I also listed my hardware, openHAB version and what binding I use.
I have read all documentation and forum posts concerning not only this sensors but all battery powered zwave devices I could find on this forum and couldn’t fix the issue so I posted my problem here.
What other details would you like me to give you? :slight_smile:

#4

I have no clue what a “referenceDB” is :smiley:
Also I did not use Fibaro yet.
I can just try to gather more information so other people who work with that type of hardware can help better and faster.

#5

I tried to find a way to show what exact sensors I have and by googling referenceID+zwave in google you can find things like:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/878?layout=openhab2

I don’t know if this is enough, but I’m ofc willing to provide every needed detail :slight_smile:

#6

can you go to habmin and compare the values from “Device Configuration - Polling Period” and “Wakeup Configuration”

  1. Are these values the same for all 3 devices?
  2. The parameter config change does not happen at the moment you change it, it needed the next wakeup interval to push it to the device. Did i you changed (20 and 21) them?
#7

Polling period is the same for all of them - 1 hour. I tried changing it but it didn’t make any difference. In wakeup configuration the one working correctly is set to 3600, another one to 4200 (can’t set it any lower) and the worst behaving one is set to 27600 (and also can’t be set any lower). 20 and 21 are set to “1” in all three right now, but this setting does not seem to make any difference at all.

#8

Have you a lifeline association?

1 Like
#9

It wasn’t set - all associations fields were empty. I didn’t touch them, because I thought that they are on default settings.
After reading your reply I set all associations to “Controller” and it looks like it did the trick!
Right now the sensors are sending temperature changes in what looks like real-time so I’m a little worried about battery life, so I need a little more testing before I mark thread as solved :blush:

#10

Glad it worked.

Just be carefull to set the reporting interval to a sensible value or you will flood your network with many not required readings. I have a feeling it defaults to a very regular report. This will run your battery down and fill your network with noise.

I think the smoke sensor also defaults to 0.1C change report. I normally increase this to 0.5 or 1 unless I am using the value for something important and need to see smaller changes faster.

#11

OK, but from what I understand setting parameters 20 and 21 only applies to setting how often sensor will read temperature (and ignore change if it’s below value set in 21), but not how often it will report this to controller.
Or does it work in a way that if it didn’t read and acknowledge those changes it will not wake up and communicate it to controller?

#12

20 defines the minimum time between reports and 21 how much change triggers a report so if the device is in a room that varies +/- 0.1 in temperature you could get a report every 10s by default.

Reducing this improves the battery life and also leaving it can cause issues on your network.

If you only have a few devices and need 0.1 changes within 10s of change then don’t worry but if you are planning 80+ devices you may want to tune it down.,

Rational:

Each report can hold the network for 100ms or more so only 10ish messages a second as a guideline level accepting that at times it will peak above this and small pauses will be noticed. Routed messages may take more and if a device has poor reception and tries different routes even more.

If you have lots of reporting device, temperature, energy or humidity reports you might see a level of traffic that will sometimes cause small delays when you want to switch a device.

I have a few of these and set mine to 5 minutes 0.5 and have never thought response and how long to trigger scenes was an issue and battery life increased a lot.

1 Like
ZWave binding updates
#13

Everything seems to work fine after setting Device Association to Controller. Sensors post temperature info as often as I set them in 20.
Thank you, robmac! :smile:

#14

You only need the lifeline set. It will send all reports to that group.

It will not do too much harm in this case but it is not necessary. If you have an alarm it will send multiple reports to the controller the way you have it.

#15

Unfortunately problem came back after few days :frowning:
Yesterday I noticed that temperatures stopped updating. When I looked into configuration all lifeline associations were blank and some other association groups were set to myserious “node_1”.
I configured all lifelines back to Controller, ran around home to wake up all sensors and they came back online.
After reboot all associations were gone.
Steps I did trying to repair:
reinstalled zwave binding (no change here, I’m on stable official 2.4.0)
removed controller thing and added it again
removed and added again nodes
unlinked one of the sensors from controller, did factory reset, then included it again
Still no dice. Associations disappear after some time and on every reboot.
Any clues?

#16

Please use 2.5 - at least M1.

#17

EDIT: Resolved by configuring serial ports in openhabian-config

I’ll post update about main issue once z-wave settles a bit because I needed to readd all things.

UPDATE:

Still loosing lifeline in 2.5M1

OK, I switched to 2.5M1 but I can’t get controller online.
After update I got
OFFLINE - COMMUNICATION_ERROR Serial Error: Port {0} does not exist
I readded EXTRA_JAVA_OPTS=-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB-ZWAVE to config.
lrwxrwxrwx 1 root root 7 Apr 24 11:28 /dev/ttyUSB-ZWAVE -> ttyACM0

I deleted controller and tried to readd it again, but I can select no ports in PaperUI :frowning:

#18

Please post a debug log showing this actually happening. It should not be possible to remove the lifeline in the latest binding, so if you can provide the log showing this being removed, I will take a look at it.

Note that the UIs have problems displaying this information, and you need to be careful is assessing this - don’t trust the UI.

#19

You may be right about that display in UI - I looked this morning and PaperUI shows blank but HABmin properly shows associations. Looks like things improved after installing 2.5M1, because sensors resumed posting temperature info :slight_smile:
I’m keeping zwave logs in debug mode and will update this thread if something starts happening to associations.
Thank you!

1 Like
#20

Aaaand it happened again. Everything was OK for a few days, so I disabled debug logging, but looks like it’s time to reenable it and leave it for about a week.
3 of 4 sensors stopped updating temperature between wakeup timer (on one sensor lowest value I can set is 27600 seconds), and all association groups are empty in UI.

14
Zrzut ekranu 2019-04-29 o 08.41.14.png1524×472 18.9 KB
25
Zrzut ekranu 2019-04-29 o 08.40.25.png1308×1432 138 KB