Hi All,
Herewith an update of my effort to get this working correctly. I decided to try and work with the analogue value coming from the TCRT5000. I adapted the original MySensors watermeter sketch to enable the use of the analogue input. I put in a software hysteresis mechanism and ‘tools’ to check the values coming from the TCRT. This appeared to be very successful the setup has been running now 24/7 since January 1st. The result so fa is zero miscounts! The counter value is the same as the reading on the meter itself. I will post more details later and I will upload everything to Github, so the code, the pictures of the setup and the PCB I’m developing for this.

Hi all,

I. m facing similar problems. like you. I was working on upgrading my network to 2.1.1. I got stuck with strange behaviour of the GW. I programmed it with:
IDE version: 1.8.4
Arduino AVR release: 1.6.20
The latest 2.1.1 downloaded libraries and the latest GW version.

After connecting the GW to my network, i was perfectly able to ping it. MYScontroller could connect, however sending a command to the gateway rusults in an error (ERROR 10054).

I've been fighting with it for a day, exchanging compontents, rebuilding SW, etc.

Here is what solved it!
Changed the AVR release to 1.6.11

I know there are problems in AVR 1.6.X, but these should have been solved in 1.6.18 and higher. Apperantly that is not the case.

I hope this helps!

Ralph

Hi All,

Resolved this with a simple funtion splitting the value in byte long parts. Bit shifting and OR are a perfect fit for this :-).

The code:

void storeEeprom(int pos, int value) {
	// function for saving the values to the internal EEPROM
	// value = the value to be stored (as int)
	// pos = the first byte position to store the value in
	// only two bytes can be stored with this function (max 32.767)
	gw.saveState(pos, ((unsigned int)value >> 8 ));
	pos++;
	gw.saveState(pos, (value & 0xff));
}

int readEeprom(int pos) {
	// function for reading the values from the internal EEPROM
	// pos = the first byte position to read the value from 

	int hiByte;
	int loByte;

	hiByte = gw.loadState(pos) << 8;
	pos++;
	loByte = gw.loadState(pos);
	return (hiByte | loByte);
}

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.

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.

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.

@mfalkvidd Thx: sometimes life is so simple. I totally did not notice that this slipped in...
Problem solved!

And to answer my other question myself: I don't need to enable softspi in the MyConfig.h I guess. Works without it apperently.

@mfalkvidd Aha clear, but the mismatch stays the same, isn't it? Anyway lets close this thread, DHT is running now, so I'm happy :-).

@samuel-wieczorek Hi Samuel. I positioned the sensor over the 1 liter wheel. I did not used the TCRT5000 module, but made a custom built PCB. Howver the principle is the same (in fact the schematics is 100% the same as the TCRT module.
If you go to https://www.openhardware.io/view/15/Itron-Aquadis-watermeter-sensor-V10 you can see pictures of the module. Some tips I can share with you:
Shield the sensor and the rotating disk area from incoming light. This influences the sensor. Use a piece of plastic tube for example. In NL we have electrical wire tubes that can be used (the grey ones)
Bring the sensor close to the disk. The reflection should do the rest. Setting up the TCRT is tricky as you have little room to manouver (considering reflection and the point where the schmit trigger swaps state)
Be aware that when the disk stops with the edge near the sensor you get false readings. That is why I swapped to a software driven solution using SW hysteresis on the arduino.
Hope this helps. If you can open it, I can share a DXF file with the sizes of the bottom plate I use. Let me know!

Ralph

Hi All,

Like the design thinking of this, although an older topic I did manage to get me one of these dishes. After taking it apart, I have one question that came to mind. Is the ventilation in the dish enough for the humity sensor? Is there any experience with that after running this sensor for a while?

Thx

Ralph

No hurries here! First celebrate the new year

Hi dbemowsk,

Can you post some more details on your projects, like schematics

Thanks in advance!

Ralph

Hi There Sineverba,

Can you post some more details on this project, like the schematics.

A more detailed BOM would also be great!

Thanks!

Ralph

Hi all,

I. m facing similar problems. like you. I was working on upgrading my network to 2.1.1. I got stuck with strange behaviour of the GW. I programmed it with:
IDE version: 1.8.4
Arduino AVR release: 1.6.20
The latest 2.1.1 downloaded libraries and the latest GW version.

After connecting the GW to my network, i was perfectly able to ping it. MYScontroller could connect, however sending a command to the gateway rusults in an error (ERROR 10054).

I've been fighting with it for a day, exchanging compontents, rebuilding SW, etc.

Here is what solved it!
Changed the AVR release to 1.6.11

I know there are problems in AVR 1.6.X, but these should have been solved in 1.6.18 and higher. Apperantly that is not the case.

I hope this helps!

Ralph

@Reza Ok, and you did check the library compiled with your sketch is the correct one? the error is exactly the same as I had, so it really looks like you are using a different library. This is a tricky thing, so please check. What IDE are you using?

@Reza Hi Reza, sorry for the little delay in replying. Anyway, read the response of @mfalkvidd 4 steps up. He gives the link for the correct library. If that does not work, there might be another problem with your libraries. Did you check if you really are using the correct one. Sometimes the old one is persistent, so you think you have the correct one, but in practice you don't. Compare the one you have downloaded with the one in your IDE to be sure.

Ralph

@xydix NRF modules are sensitive to power fluctuations, so take care that you have a stable source. Is the booster of good quality or producing noise on the power lines?. The converter can produce a high frequency signal on the powerline, also know as noise. You can try to filter the noise with a small capacitor like 100nF or maybee even smaller depending on the freqency of the noise coming from the booster.
My problem was/is the distance between the GW and the sensor currently, other problems were related to power as well, solved for now (see above my findings)

@rubyan Sounds like power trouble and/or distance between GW and sensor. Powering from the Nano is in genaral not a good thing. The supply might be to week. Use an external power source and some capacitors (see above) Also try to see if putting the GW and sensors at a distance helps.

@TheoL Agreed, better safe then sorry :-). I'm interested to see how the sensors will perform if they are close together (they will probably be in a class room kind of situation). I found that this is one of my biggest pitfalls. 1.5 was always ok, even on the same work bench. 2.0 is very critical in this in my experience. For myself I wonder how this is going to work in real life situations where sensors might be close range to eachother and to the GW. If have not enough sensors now to test this on 2.0 unfortunatly, but you will have I guess some during the workshop.