Gas New presentation and subtype

[ericvdb]

Hi,

would it be possible to add S_GAS and V_M3 (or V_CM for cubic meter).

There are lots of gas meters that can be sensed with a hall-effect sensor and each pulse is 0.01m³ (depending on the gas meter type/brand)

Thanks in advance.

[ericvdb]

So nobody is measuring it's gas consumption?

@hek And to correct a bit, V_M3 is not needed because V_Volume and V_Flow can be used, but V_Counter would be nice. With V_Counter we could store the real meter readings.

[ahhk]

I thought a lot about measuring gas. A lot of people just transmit the impulses and the controller (Openhab,...) calculate the usage on a daily/hourly/monthly basis. I think it is not a good idea to store the gas counter or calculate the volume in the sensor. It's easier to add (and from time to time to correct) this as an "offset"-value in the controller. In short words:

• Sensor only send one "ping" for each impuls of the gasmeter
• The controller summates the pings based on your wishes and calculates the volumes / averages (...). perhaps in a RRD..
• The total gasmeter status is the sum of the point before plus an "offset"...

Greetings

Andreas

[ericvdb]

@ahhk said:

A lot of people just transmit the impulses and the controller (Openhab,...) calculate the usage on a daily/hourly/monthly basis. I think it is not a good idea to store the gas counter or calculate the volume in the sensor.

I don't think I said to store the counter on the sensor node. But I do think it is a good idea. Usually the sensor node is pretty stable and in my casy mains powered, so why not store the counter also on the node. This helps a lot if you regularly make changes to the controller. The sensor always sends the right counter to the controller.

If your controller is down for 5 minutes, you will not receive the pulses in those 5 minutes and your counter on the controller is not correct anymore.

Doesn't take away that a request for S_GAS type is valid.

[hek]

@ericvdb Might be good to have a gas meter sensor type.

Storing pulses in EEPROM is not optimal and will wear it down.

@ahhk, the pulse (delta) idea is good. Thought about the it when implementing the old meetering devices (water, electricity) but at the time I didn't have the time or energy to build the device config/gui needed on Vera. Also, lost messages (pulses) will not be recoverable.

[ahhk]

Hi,

i decided for me, thats it is the easyiest way for me to update the "offset" in the controller (openhab) manually (maybe by entering the value on the website), than updating the sensors eeprom. The pulses i lost during controller-offline-times is so small - not a problem for me. Its is more than enough for me to update the offset 2 or 3 times per year...
When you want to store the value in the sensor, than you have other topics to solve:

• how often is the value stored in eeprom? after every pulse? after every 100 pulses? (value will be wrong if the sensor resets before the last value is stored)
• how to calculate the daily /hourly/weekly/monthly values?
• what about visualisation (graphs)?
• when only pulses are transmitted, the sensor needs to be "read-only" only. no need to update internal gas-total-value OTA...

So (for me!) storing the pulses in a RRD (type counter) is still the easyist thing and my openhab is running very stable on my raspberry. I dont change this "productive" system and develop new features on separate system. Downtimes are at minimum - just perfect for my situation....

[hek]

Yes, agree, Just sending pulses has its advantages.