General Discussion

Ok, could not find the root cause for why the embedded forum thread on openhardware.io couldn't detect if user has a valid session/is logged in to the forum. Did a workaround by adding a "Comment" button which redirect user to the thread on the forum.

@skywatch There is also the next "Yet another Arduino with fancy hardware but poor library support" planned: Arduino Nano RP2040 Connect [image: arduino_nano_rp2040_connect-1024x576.png]

@pihome Please read full coment before answering. I wrote: ...everithing works well i push reset button on...

Couple of things to think about with capacitors. With electrolytic caps there ESR ( Equivalent Series Resistance) is quite high if you need a lower ESR try going for a polymer electrolytic. Ceramic capacitors, as previously said don’t go for a capacitor that is rated at the same voltage, in my experience at least 1.5 to 3 times the max voltage your working with. So if your working with 5V I would go with a 16V part. The reason for this is the DC BIAS of ceramic capacitors, if you need 1uF of capacitance and use a 6.3V cap the DC BIAS of the capacitor could only 20% to 30% of the stated capacitance. Therefore you would need 3 or 4 capacitors at 6.3V to get the correct capacitance where as with a 16V part you may only need 2 capacitors in parallel to achieve the correct capacitance. Most good capacitor manufactures will have these online in the specifications area of there website. Also be careful depending on the power supply your using they may need electrolytic as the ESR of ceramics is very low and this can cause the power supply to become unstable as the control loop of the power supply can’t cope. These are lessons learned over the years as I alway say you learn more from making a mistake than being told what to do and getting it correct 100% of the time.

@zboblamont & @mfalkvidd - Thank you for that. It never occured to me that rounding might need some help. But now it makes logical sense. @mfalkvidd I guess if you used 'bankers rounding' you would always end up with 0.

@Nca78 Great - I have some of those somewhere (next mamoth task is to find them)! - Then I can remove the regulator and will report back! All done! With sensor only I am seeing 12.9uA in 'untripped' mode and 14.2uA when tripped for about 2 seconds - that is a result! Testing further this module seems to work down to 1.9V which is ideal. Here is a table of results I get.... Voltage Vcc (V) Untripped (uA) Tripped (uA) 3.0 12.9 14.2 2.7 9.4 10.3 2.5 8.5 9.6 2.3 7.7 8.8 2.1 7.0 8.0 1.9 6.3 7.3 These are 'bench' measurements and may not reflect 'in use' performance (ie range may be reduced at lower voltages, I have not tested that yet). Thanks so much for the hints, I only now have to test out to see if the range and spread is good enough for what I need. Maybe later on today or tomorrow.... Cheers! :)

In sketch definitions: ... MyMessage msg1valve(CHILD_ID_IRRIGATION_SYSTEM, V_LIGHT); MyMessage var1valve(CHILD_ID_IRRIGATION_SYSTEM, V_VAR1); MyMessage var2valve(CHILD_ID_IRRIGATION_SYSTEM, V_VAR2); MyMessage var3valve(CHILD_ID_IRRIGATION_SYSTEM, V_TEXT); .. in sketch receive function: ... if (message.type == V_LIGHT) { ... } else if (message.type == V_VAR1) { int variable1 = atoi(message.data);// RUN_ALL_ZONES time DEBUG_PRINT(F("Recibida V_VAR1 de la válvula:")); DEBUG_PRINT(i); DEBUG_PRINT(F(" = ")); DEBUG_PRINTLN(variable1); if (variable1 != allZoneTime[i]) // es un valor diferente del que había anteriormente { allZoneTime[i] = variable1; zoneTimeUpdate = true; //enviar valor al contrtolador send(var1valve.setSensor(i).set(variable1), false); } receivedInitialValue = true; } else if (message.type == V_VAR2) { int variable2 = atoi(message.data);// RUN_SINGLE_ZONE time DEBUG_PRINT(F("Recibida V_VAR2 de la válvula:")); DEBUG_PRINT(i); DEBUG_PRINT(F(" = ")); DEBUG_PRINTLN(variable2); if (variable2 != valveSoloTime[i]) // es un valor diferente del que había anteriormente { valveSoloTime[i] = variable2; zoneTimeUpdate = true; //enviar valor al contrtolador send(var2valve.setSensor(i).set(variable2), false); } receivedInitialValue = true; } else if (message.type == V_TEXT) { String newMessage = String(message.data); if (newMessage.length() == 0) { DEBUG_PRINT(F("No se ha recibido NOMBRE (V_TEXT) para la zona ")); DEBUG_PRINTLN(i); break; } if (newMessage.length() > 16) { newMessage.substring(0, 16); } valveNickName[i] = ""; valveNickName[i] += newMessage; String val = String(valveNickName[i]); DEBUG_PRINT(F("Recibida V_TEXT de la válvula: ")); DEBUG_PRINT(i); DEBUG_PRINT(F(" = ")); DEBUG_PRINTLN(valveNickName[i]); } receivedInitialValue = true; } ... In domoticz: each scene for each valve who on action: script://exec.sh irrigation_single_zone 10 1 0 5 "Zona 1" in /domoticz/scripts/exec.sh: #!/bin/sh case $1 in irrigation_single_zone) python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=$3 --time_all_zones=$4 --time_single_zone=$5 --n$ exit 0 ;; irrigation_all_zones) python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=1 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=2 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=3 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=4 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=5 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=6 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=7 --time_all_zones=$3 >/dev/null 2>&1 & python /home/pi/domoticz/scripts/python/send_vars_to_irrigation_system.py --nodo_id=$2 --child_id=8 --time_all_zones=$3 >/dev/null 2>&1 & exit 0 ;; esac /domoticz/scripts/python/send_vars_to_irrigation_system.py: #!/usr/bin/python3 import socket from time import sleep import sys import argparse #import DomoticzEvents as DE def gwsend(args): nodoID = str.encode(str(args.nodo_id)) childID = str.encode(str(args.child_id)) timeAllZones = str.encode(str(args.time_all_zones)) timeSingleZone = str.encode(str(args.time_single_zone)) nameZone = args.name_zone s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("127.0.0.1", 5003)) sleep(3) #estructura del mensaje #99: Node ID #1: ChildId #1: command (Set in this case) #0: ACK (None in this case) #47: V_TYPE (V_TEXT in this case), 24-25-26 V_VAR1-2-3 #enviar tiempo duracion en modo All Zones (V_VAR1 -> value 24) if timeAllZones != "None": s.sendall(b"" + nodoID + ";" + childID + ";1;0;24;" + timeAllZones + b"\n") sleep(3) #enviar tiempo de duracion en modo Single zone(V_VAR2 -> value 25) if timeSingleZone != "None": s.sendall(b"" + nodoID + ";" + childID + ";1;0;25;" + timeSingleZone + b"\n") sleep(3) #enviar nombre de zona (V_VAR3 -> value 26) if nameZone is not None: s.sendall(b"" + nodoID + ";" + childID + ";1;0;47;" + nameZone + b"\n") sleep(3) s.shutdown(socket.SHUT_WR) s.close() def main(): my_parser = argparse.ArgumentParser(prog='send_vars_to_irrigation_system', usage='%(prog)s --nodo_id=NODO_ID --child_id=VALVULA_ID, [--time_all_zones=TIME_EN_MODO_TODAS] [--time_single_zone$ description='Envio de parametros de cada zona al sistema de riego') my_parser.version = '1.0' my_parser.add_argument('--nodo_id', type=int, action='store', required=True, help='ID del nodo Sistema de Riego') my_parser.add_argument('--child_id', type=int, action='store', required=True, help='ID de la valvula') my_parser.add_argument('--time_all_zones', type=int, action='store', required=False, help='Duracion en modo Todas las zonas') my_parser.add_argument('--time_single_zone', type=int, action='store', required=False, help='Duracion en modo Solo esta zona') my_parser.add_argument('--name_zone', type=str, action='store', required=False, help='Nombre de la zona') args = my_parser.parse_args() gwsend(args) if name == 'main': main()

AFter more testing it just got better. It seems that the atmel 168 has enough memory (just) for mysensors running nrf24, 2x interrupts and a HTU21D temp and humidity sensor. I tested overnight and it is working as expected. I didn't think the chip was as capable as it appears to be! Also good is that I have tested it working down to 1.64V. This works even sending the temp and hum values, but at 1.63V it no longer transmits anything. Looking at the standard mysensors battery page it seems that the battery percentage is sent using 0V as 0% and Vcc as 100%. In practice the battery levels will be unlikely to go below 50% giving a false reading of how much drop in voltage has actually occured. To make it more accurate I have set brown out voltage as 0% and Vcc as 100% giving the full range to the expected battery life which is a more accurate reflection of battery usage and time left. Here is the code I used to do it...Only the bits added for this to work, include in your own sketch if you want. int oldBatteryPcnt = 0; int batteryPcnt = 0; long result = 0; float vSend = 0.; float BattMax = 3.00; // Maximum battery voltage (take reading before using or use battery rated value...) float brown_out_voltage = 1.7; //lowest battery voltage equating to 0% battery power (ie battery empty). float brown_out = 0.; float divisor = 0.; void setup() { divisor = BattMax / 1024; //Set batt 100% - here it is 3V/1024 brown_out = brown_out_voltage / divisor; //Set batt 0% to brown out voltage } void loop() { readVcc(); //only if using internal method, if not replace with external value. vSend = float((result) / 1000.0); //calc and send batt percent to controller... float sensorValue = vSend / divisor; //Get voltage % int sensorVal = constrain(sensorValue, brown_out, 1023); //constrain values. batteryPcnt = map (sensorVal, brown_out, 1023, 0, 100); //Integer pcnt value. if (oldBatteryPcnt != batteryPcnt) { sendBatteryLevel(batteryPcnt); oldBatteryPcnt = batteryPcnt; } } Now you have percentage between brown out voltage (either measured with volt meter or using the fuse value set on node) as 0% and Vcc (either measured with a volt meter or set for the battery type/combination) as 100% at new.

@BearWithBeard I think that an 80% loss rate is not good whatever the reason. I have suggested a 'knowledge base' in another thread today as a place to keep all updated and more advanced info in one place for reference. For starters I suggest 5 areas that crop up again and again..... Bootloaders Battery Powered nodes Signing Encryption FOTA So have a knowledge base for each of the above with all the hints and tips up-to-date in one place with example code snippets.

@skywatch better safe than sorry :) I can imagine this question being ask completely seriously.

@skywatch hah, tell me about it. it went through battery and all. Still dutifully reporting every 3 minutes.

I use these: https://www.aliexpress.com/item/32855681042.html Well, they work, but profile is not the best for dupont (2.5mm). But for their price it's ok.

Dear MaxG. Thank you for your interest. «I am missing units of measure in the graphs» - You are right. I didn't put the units of measurement in the graphs. I described the graphs in the beginning of every paragraph. «Why is there a significant dip at 50?» - every sensor has its own transient response. Some pyroelectric detectors are faster, some not. Serial opposed dual pyroelectric detectors have transient responses longer than parallel. I found value 50s to be approximately good for all of the samples. Also, this value is comparable with the scale of percentage, so 100s, or 100%, is the length of the full period, and 50s, or 50%, if that of one of the two transient responses, heating or cooling respectively. [image: 1609243119568-663cf0d1-3c9d-422e-ab86-709dfef91a05-image.png] «Maybe overlaying the sensors in one graph per category would allow for a quick comparison of the response.» - every graph includes four lines. If I overlay all of them one another, I'm afraid, we will receive chaos. I think It would be a good idea to overlay the approximations only. What are you thinking? «A summary/conclusion would also be helpful to the reader.» - You are right twice. But I didn“t do it for the next reasons. This method is too young, the first attempt. I don't have enough knowledge, skills or practical experience do write conclusion. When a half of the year have passed by, I will, probably, be able to write good, professional conclusions. As the author, I am also interested in the opinion/conclusions of the other people. This is why I have posted it here. If you have more questions, please, feel free to ask. If you know the other people interesting in pyroelectric measurements, invite them to this discussion. This topic is brand new. I am looking for more feedbacks and opinions. I'll be glad to receive positive, but also accept critics. The truth is born in discussions. Kind regards in return. P.S. you can even think about carrying out the same measurements all by yourself. If you find a way how to test motion sensors to avoid false alarms, you will be able to earn something.

No, I define the number of pulses for 1m3. This data is theoretical and to be verified. Adjusted to 300,000 pulses per m3 or 6,000 pulses per 20 liters, I obtain an actual volume of 15 liters. So I had for 6000 pulses a volume of 15 liters. So if I had waited to have one m3, I would have had 1000 liters / 15 liters = 66.67 * 6000 pulses = 400,000 pulses per m3. For your second sentence I agree and that is the problem.

@mfalkvidd If the message was sent by a cat, maybe...... ;)

My lab partners think we should use the center of the 1st gaussian as the real peak, because the presence of the second peak influences the position of the first within the data as in, we aren't talking about the fitted-function, we are talking about the data points themselves.