Counting pulses - wind speed

Setup, Configuration and Use Scripts & Rules
1

I am planning to connect a wind speed sensor to Openhab2 (RPi3 and GPIO). The sensor will send pulses - maximum 3-5 per second. How to read the current value of pulses in Openhab? (without counting only the amount per second at a time).
The pulses will be sent by an analog wind sensor.

2

I would use something other than openHAB to count and publish via mqtt or filesystem.

Write a python, perl, or other program.

I say this as I am afraid openHAB would possibly get tied up with this task.

1 Like
3

I have written a Python program for interfacing GPIO on RPi and other SBCs. While it currently doesn’t have a counter function it would be trivial to add it. You can check out MQTTany on Github. Feel free to take a stab at adding a counter pin type to the GPIO module yourself if you want.

I have created an issue to track this. If you aren’t interested in working on it, this is a feature worth adding and I can probably work on it this weekend. Your help testing it would be appreciated if you are interested.

2 Likes
4

This can be done with a 1 minute con rule using persistence. This gives you the amount of pulses in the last minute. Note this does not give instantaneous readings, but readings every minute. This example uses influxdb but you can substitute whatever persistence service you are using. You will have to figure out what your multiplier is, which is what the wind speed is after a certain number of rotations in a minute.

Wind_Speed.postUpdate((Wind_Pulses.state as DecimalType) - (Wind_Pulses.historicState(now.minusMinutes(1),"influxdb").state as DecimalType) * multiplier)

You may want to add something to test for NULL or UNDEF states, as well as something if the wind pulse counter rolls back over to 0.

1 Like
5

This solution will be the best for me.
Can you give me what this rule should look like? I tried to write but it doesn’t work.

6

What doesn’t work?

Make sure your item that counts the number of pulses is persisted (in this case Wind_Pulses). See: https://www.openhab.org/docs/configuration/persistence.html
I haven’t tested this so there may be errors.

rule "Cron Minute"
when
	Time cron "0 0/1 * * * ?"	//update every minute
then
    var multiplier = 0.04   //you have to figure out your own value from the datasheet
    Wind_Speed.postUpdate((Wind_Pulses.state as DecimalType) - (Wind_Pulses.historicState(now.minusMinutes(1),"influxdb").state as DecimalType) * multiplier)  //change influxdb to whatever persistence service you are using.
end
7

First you would need to have an Item that counts pulses in a minute.

8

Hi.
I have added the role indicated by g_g_rich and to
sitemaps:

Text item=Wind_Speed

Items

Contact Wind_Pulse {gpio =“pin=16”}
Number Wind_Speed

Still, it doesn’t work. What did I do wrong?

There is an error in the logs:

Configuration model ‘wind.rules’ has errors, therefore ignoring it: [7,105]: extraneous input ‘)’ expecting ‘end’

9

You would still need an Item that counts.

This Item does not count, it can be CLOSED or OPEN.

There’s something wrong in your rules file, probably mis-matched brackets. Count ( and )

The VSCode editor with openHAB extension is something else to install and download, but will highlight errors like this. Might be useful if you plan on making more rules etc. later.

10

Ah, ok. My item counts the number of pulses.
I know influxdb stores CONTACT as 0 and 1, so you could use something like:

Wind_Speed.postUpdate(Wind_Pulses.sumSince(now.minusMinutes(1),"influxdb")  * multiplier)
11

You’d need to be sure to store everyChange.
5 pulses per second would be 10 changes per second, I think that might be pushing your luck on a Pi or similar. And when a hurricane comes 
 ?
Not sure this is a viable approach in practical terms, think I would look into a counting rule.

12

@rossko57 this wouldn’t be pushing anything on a Pi unless you were trying to do it in OH. I recently saw something suggesting the new GPIO character device kernel module could top out in the neighbourhood of 100k pulses a second. OH would never be able to keep up with that, I’m not even sure Python could but it would get much closer.

13

@sliver001 are you still interested in trying MQTTany for this? I know I said I would get to it a month ago, but plans change. I ended up finishing some major reworking of MQTTany that actually made implementing this easier.

If you are interested in testing, send me a PM. I have some code ready to test.

14

The suggestion here was to be doing it in OH, using OH persistence to store data away at ~100mS intervals in normal use and peaking at maybe 10mS? 5mS? sustained intervals.
I don’t think that’s a good idea and advise something else - counting not storing.

1 Like
15

Sorry, I misunderstood. I thought you meant on a Pi using any means. I totally agree, and I’m skeptical if that kind of interval would even be feasible on desktop hardware using a rule, never mind persistence.

16

For anyone interested, MQTTany now has pulse counter support. Currently it is only available in the development version (v0.11.0-dev) on the master branch but will be part of the next release. Documentation will be up shortly in the docs branch but won’t be published until the next release.

I have no pulse generating hardware, so my tests were limited to switching a pin by hand and monitoring the results.