Water meter: Itron Aquadis+ with pulse sensor

[bisschopsr]

Hi all,

The design and the sketch are on github. Link
https://github.com/rbisschops/mySensors/tree/master/Watermeter

This is an early stage design. Any feedback is welcome!

Ralph

[bisschopsr]

Hi All,

The water meter sensor has been running as of Jan 1st without a litre deviation compared to the actual water meter reading. That is 2 month! This week I received the most of the parts for the board. Made some final changed to the layout (see Github and Openhardware.io for the files). This week I will do a final quality check on the board. After that the order for the board goes out.

[bisschopsr]

Just the let you know, the board is submitted for production (V0.10). Now I have to wait patiently. Meanwhile I probably will work on the sketch, get the parts not used anymore out. Also I need to further write the manual.

[Klon]

Thanks for developing this. It works excellent with my water meter flawlessly, but does not appear to me the "water flow". No device in the domoticz.

[bisschopsr]

@Klon This might be a Domoticz problem. DO you see water flow when you for instance connect with a tool like MYSController? My interest is about counting water consumption, so I did not pay attention to flow (yet). I dismantled the test setup a week ago, so can't test.

[bisschopsr]

I just received the PCB's, so I will start to build the first proto somewhere this week. I will update the progress to the forum as soon as I have results.

[Klon]

Unfortunately in MYSControler also does not have information about the flow of water.

[bisschopsr]

@Klon: Hi Klon, I chacked the code. It might be that the flow is not sent becaus I disabled the interupt of D3. I will have to make some changes to the code to get it working again. I will look into it.

[bisschopsr]

Hi all I soldered the PCB's this week. There is one little error in the boards, so not to bad. Today I tested the board for the first time. It is working perfectly. I must however say that the board does not yet contain the EEPROM and the ATSHA, so that part is not tested (yet). I also have to adapt the sketch for the Temperature sensor (SI7021), so that parts also remains to be tested.
Herewith some pictures of the PCB.

[bisschopsr]

Hi All,
Just to add a picture of the assembled sensor with its housing. The housing was a little strugle to get it to fit the meter. The top of the meter is not flat. Eventually I found the best fitting solution. The "housing" was laser cut and consists of three parts, a base plate, a plate to fit the PCB and a protective top plate with some text. The base plate has a screw to fixate the sensor to the meter.

I will post a picture of the sensor on the meter later.

[bisschopsr]

Hi All,

The sensor is finally in production on my home water meter. I just uploaded the latest version of the pcb documents to OpenHardware.io. Not bad only one small error in the PCB design. Easily fixed so no need for ordering new boards.

[Yveaux]

@bisschopsr Thanks for sharing! :+1:
Will you be able to make it to the MySensors meetup at July 30th in Breda?
Would be very nice if you can show it there!

[bisschopsr]

Hi @Yveaux thanks for bringing the meetup to my attention. I will look at it (found the thread). As this is very close to my summer holiday I will have to see if I can be there. I will keep you posted.

Thanks

Ralph

[bisschopsr]

@hek : I'm in the process of converting my sketch to the 2.0.0 release of mySensors. As I work in Visual Studio (instead of the standard IDE) I noticed that there is an error generated for the following line:

send(lastCounterMsg.set(pulseCount));

This line is also in the original (converted) sketch at line 140. If I change the line in line with the other send commands so something like this:

send(lastCounterMsg.set(pulseCount,3));

the error is gone.

So my questions are:
What is the correct way to write the code line?
Is the 2.0.0 release more critical to this?

Note: The standard IDE compiles the code without an error.
Thx in advance,

Ralph

[hek]

Using the following feels wrong. It isn't a float value you're transmitting.

send(lastCounterMsg.set(pulseCount,3));

[Yveaux]

@bisschopsr can you post the error message? Maybe that will help in fixing the error...

[bisschopsr]

@hek: I agree with you, its not a float. I tried it to see how the interperter of VS responds. I did not mention this eralier, but I use the Visual Micro plugin in VS.
@Yveaux: I took a quick screenshot of the error message:

As I see it the interperter expects the function as it is, somehow it does report an error though.

Regards,
Ralph

[Yveaux]

@bisschopsr thanks for posting the actual error message; that helps a lot :smile:
Apparently the type of pulseCount is volatile unsigned long.
The MyMessage class has no set() - method directly taking this type as input, so the compiler starts looking for the next closest match. It finds 3: bool, uint8_t and int32_t and can't make a choice. That's why you get the error.
To fix it, either change the type of pulseCount to one of the supported types, or cast it to one of these types just before calling the set() - method on the message.

[bisschopsr]

@Yveaux As you might have understood, I'm not that experienced in the language. But I think I get the explanation you gave. Indeed pulseCount is of type volatile unsigned long. So if I change it to for example int32_t, will the Arduino compiler still understand and use a similar type as unsigned long? On the other hand, I guess this is related to the libraries of mySensors, isn’t it? So should the library not support unsigned long as well?

Thanks again,

Ralph

[Yveaux]

@bisschopsr depends... Currently the library understands a lot of c++ types, but not all as you have seen.
Choosing a comparable type will simply fix your issues. The int32_t is identical to unsigned long on Arduino, except for the sign. If your values do not exceed 2^31 you can just as well store it in an int32_t, but keep the volatile: volatile uint32_t pulseCount
Maybe we can add some template trickery to the library to support all c++ types.