Binary sensor connected to Smart implant not reporting 0 after first reproted 0

[Neo Andersson 184]

Hello guys

Anyone of you can give some support here please?

 

I have connected a analog wind sensor to an implant.  

There are two major questions for me.

 

1. What determines, how often will be any value change reported to Gateway? See the attached picture. I have enabled even periodical reports, and minmal report changes, and everything is set up as it sholud be, but there is still no definitive answer what makes the implant to report values.

Now there are coming quite randomly. Firts report comes like 20-30 second after the wind start to blow. Second report comes 10-15 sec after the first one, the third comes like 30-40 sec, and all reports are coming in chaotic way.

 

 

2. The very strange thing is...If the wind stops, then we got reported the 0 value, what is okay. However, after this zero value, the reports are not coming if the wind still not blows. So if the wind stopped to blow at 18:00 pm today, and wont start until next day, my last report will be always dated back to 18:00 PM.

Very strange, becuase periodical reports are enabled, so implant should send reports independently from values..

 

We need it very badly, becuase we need to calculate a average wind speed from 3 measurements, but as i mentioned, if forexample the first measurement shows 1m/s wind, the second will show 0 m/s then it will not come to the thirs measurement until the wind not start to blow again, so we are unable to calculate the average..

 

Maybe this sound quite complicated, but it is actually not.

 

We are storing last 3 measurements and calculating the average. But because of this problem, our measurement average will still show some wind, because all three values never get changed to 0 if the wind stops.

 

Any experimented magician can give us some hint please ?

 

Thanks a lot

 

Please login or register to see this attachment.

Please login or register to see this attachment.

[m.roszak 535]

Hello,

Reports are being send according to thresholds and periodic intervals but upholding the limitations mandated by Z-Wave requirements (sensors can't report more often than once per minute or 30 seconds - I do not remember exact figure).
As for reports with the same value (0), it is reported by the device but as value is not changing then you don't see it in the panel. If reports with the same value will be visible every time panel will be flooded with reports.

Regards,
Michał 

[jakub.jezek 353]

For analog sensor I would suggest to use RGBW module 2 and in scene check output of the device instead of input. Reports comming evšery 5-10 seconds. But you would need to have QA or variable that interprets the value.

 

I have used Smart Implant with potentiometer (terible decision btw) and we were pretty much schooled by it on one project.

 

@m.roszak, in case of local protection turned off, it would be great if value could come in 2-3 seconds to UI, but maybe 5-10 seconds is RGBW 2 device limitation. We use Z-Wave engine 2.

[m.roszak 535]

You should be able to boost up the reports by lowering the parameters responsible for speed of the local control via buttons - faster "transition" will mean that the reports will be sent a little bit faster (if I understand correctly you are using multilevel switch reports from the output as your measured value).

[Neo Andersson 184]

We have I analog wind sesnor and a digital rain sensor connected to implant.

The problem is with the analog wind sensor. It is connected to Input1. In our case we need to get reports every X seconds or minutes independently on the value.

We have found out, that with parameter 64 we can get periodically every X minute the voltage that is measured in input1. 

The only problem is, that when there is no change in voltage, then the implant stops reporting the value.

Example.

 

We set up the periodical interval to 1 min.

So this is happens.

10:00 -------- implant sends 0.3V -- so there is some wind

10:01---------implant sends 0.5V -- so there is some heavier wind

10:02---------implant sends 0V -- so there is no wind.

and here the reporting stopps..and starts only when there will be some wind, so some other value than 0

 

 

we would need it like this. Implant should report every minute evey value. Even if its always 0.

10:03--------implant sends 0V -- so still no wind

10:04--------implant sends 0V -- so still no wind

10:05--------implant sends 0V -- so still no wind

10:06--------implant sends 0V -- so still no wind

10:07--------implant sends 0V -- so still no wind

10:08--------implant sends 0.2V -- there is wind again..

 

 

Thanks

 

 

 

 

[m.roszak 535]

Not possible right now
And as I wrote before, Impant reports those values but those are ignored in HC.

[Martin_N 146]

@Neo Andersson

ok, ... and what prevents you from making a simple error exclusion.
Every minute (or 30sec) write down the last value that came from SmartImplant and check if the wind is> 0 and then you count the average of the last 3 values?
When wind = 3x0 it is clear that wind does not blow and it is not necessary to count the average.
Depending on what you write, it may happen that it will exceptionally blow a constant quiet wind and SI will send 1x 0.3V and then nothing (because the state does not change = the same quiet wind is still blowing).
And you simply overwrite the last value in the next field in each time interval.
If there is a change of state in the meantime, nothing happens, the new value replaces the previous one and the whole thing is shifted - FIFO.

I admit, it's a bit dangerous, if the information transfer fails, you don't have the current status. It is probably possible to get the notification that the device does not communicate.

eM.

 

[Sankotronic 2,205]

21 hours ago, Neo Andersson said:

we would need it like this. Implant should report every minute evey value. Even if its always 0.

10:03--------implant sends 0V -- so still no wind

10:04--------implant sends 0V -- so still no wind

10:05--------implant sends 0V -- so still no wind

10:06--------implant sends 0V -- so still no wind

10:07--------implant sends 0V -- so still no wind

10:08--------implant sends 0.2V -- there is wind again..

 

Since implant is reporting every minute but HC ignores report that is same as previous one then you need to write your own QA that will periodically read value regardless of the implant reports and then calculate average. Signal sampling is done by your software. You can also add checking of the last reported change so you can know how long there was no change in the wind speed. I would record value every 60 seconds and store recorded values to variable for e.g. last 3 hours range (180 records) and then with each new value read delete the oldest one. It is then also possible to send recorded values to influx database every 3 hours cycle to have nice graph of wind speed in Grafana.

 

If the wind speed is very important and must be monitored at all times then the only way of making it reliable is to have two sensors because it is a very small chance that both sensors will fail at the same time.

 

[jgab 2,048]

Long post here on calculating sliding averages and hysteresis

 

[Neo Andersson 184]

Thanks guys.

Yes I know, we can do a loop reading of implant value every minute, but i was trying to avoid this. In my QA I am catching value changes by event listening.

In the description of the parameter 64 it says, that "reports are sent periodically, independetly on the value."

Thats why wo thought it should work.

 

If there will be nothing else, I will do it according to Sankotronic's suggestion.

 

Thank you guys again

Edited March 30, 2022 by Neo Andersson

[petergebruers 1,265]

On 3/27/2022 at 9:58 PM, Neo Andersson said:

We need it very badly, becuase we need to calculate a average wind speed from 3 measurements, but as i mentioned, if forexample the first measurement shows 1m/s wind, the second will show 0 m/s then it will not come to the thirs measurement until the wind not start to blow again, so we are unable to Wcalculate the average..

 

Well, in a perfect world it is safe to assume "if I do not hear from this device, then the last reported value is still valid, and cached" and then it is a matter of applying timers and math to get your average. That's what the previous posters discuss. So let me get another angle on this...

 

If you question the reliability of this mechanism, you will have to determine how fault tolerant you want it to be. Here are some thoughts in random order

 

• Z-Wave is wireless, this means order of magnitude 1 in 10000 packets get lost, is that kind of issue acceptable? Is it handled by your software? If this is a safety feature, you might need better, wired hardware (possibly with redundancy)
• It is not a battery device, so no batteries could suddenly die. Good. But someone might unplug the power supply and with the assumption "if I do not hear from this device, then the last reported value is still valid" you got a problem. But there is a way to check the device
• Z-Wave mains device go DEAD if you communicate with them. If you try to control or poll a mains device and HC gets no answers, after about 20 seconds the device goes DEAD.
• You will have to write code to handle that, and also UN-DEAD the device. It has been discussed a few times on this forum.
• If something goes dead, your code may choose to go in emergency mode, but that might not be easy. Eg if it is a "thermostat" and does not get temp updates, in some countries you want to prevent freezing, but in other situations you want to prevent overheating. Which one to choose, turn on or turn off?

It is doable and legitimate to "ask" the mains device to report instead of using its programmed reporting mechanism... And if it cannot respond (eg because it has no power) it will get that "dead" status

 

I think the manual poll command is somewhat undocumented but it isn't rocket science. Here is code from 2019, written for HC2. I cannot rewrite it for HC3 right now, I no longer need this. But on HC2 it did serve a purpose, I used it on a light that would drop far more than 1 in 10000 packets. I fixed the root case instead of writing code...

 

 

[Neo Andersson 184]

Thank you Peter