Topics created by skywatch

@CodeGarage What I want is a lion powered Sensor if possible. And that in a case I can stick to the door frame. As I cannot screw or drill into the doorframe. But I have no idea how much current that draws.

I hope the project won't be buried due to the fact that the protocol is the basis of nippy devices (https://nippysmart.com/) I also hope that the development of mysensors won't be directed in 2 directions - one commercial only for nippy - the other for all the rest, which could result in the two versions diverging so much that they will be incompatible and the second one will simply be buried.

maybe this can be useful : https://forum.mysensors.org/topic/6948/synchronising-light-switch I use it with version 1requestState or 2 requestTime() on some sketches (I modified the structure, moved some parts to functions to make it more readable )

@skywatch said in No more batteries....: What started this was my research into Dark Matter and Dark Energy discussions with Astronomers and Scientists. I wondered why a simple atom made of one electron around a nucleus of one proton and one neutron could remain stable when the electric charges would mandate an attractive force between the positive nucleus and negative electron. The electron can 'somehow' sustain its distance and therefore gets energy to overcome the attractive force. It can do this for millions of years with no 'conventional' input of external energy. You can move electrons around atoms and molecules with relatively low chemical or electrical energy... Zero point energy is the equivalent of the remaining drops of gazoline in an empty gaz tank. If you have millions of cars with "empty" gaz tanks then you're looking at a lot of energy. But it will take you way more energy to retrieve those last drops of gazoline from each tank than you will get from burning them later. It's the same with zero point energy, getting the matter in the right conditions to be able to extract any of the remaining energy will use more energy than you will be able to collect. Right now the world could do with cleaner energy. Yes we all want it. But it doesn't mean we have to fall in the hand of all the scammers who have pretended for centuries to have discovered all by themselves the secrets of infinite energy. They've been updating the buzzwords but the scam is always the same, with demos using an hidden power source. It's the case for ecat they never ran it unconnected from a power supply, pretending it's using only little external power but it's very easy to cheat. I just hope the breakthrough comes in the west because if Russia or China leapfrog us on this tech then we are at a severe disadvantage. Breakthrough will come from international cooperation that has been happening for decades, no single country has the resources and brains to make the breakthrough all alone. I guess that 'solar power' would have been laughed at 2 generations ago (along with nuclear power, smart phones, space stations etc...) Chose better examples, a working demo of photovoltaic effect was done in 1839, way more than 2 generations ago... https://en.wikipedia.org/wiki/Solar_cell#History And for nuclear power, smart phone and space station yes it would have been laughed at if someone in 1900 had come up saying he built a smartphone, a nuclear power plant or a space station all by himself in his garage. But no one laughed at Hertz when he identified and described radio waves in 1886, 10 years later there were functional radios, and 15 years later it was getting widely available to the public. No one laughed at Fermi in 1936 when he discovered nuclear fission, only 6 years later he was running the first nuclear reactor in the US, in 1951 they were producing electricity from a nuclear reactor and in 1957 the first commercial reactor was running at full power. Only scammers make "revolutionary" discoveries in their garage while having no experience and education in physics, pretend to be victims of the "lobbies" so they have to recourse to crowdfunding, refuse to have independent testing of their devices and pretend to have been running decades of intense research but have never published anything in a half-decent peer reviewed scientific journal. When there's real science and real scientists behind it, the technology can progress fast and they have no problem getting some funding.

Thought I remembered a teardown and examination, and finally found it... Enjoy... https://youtu.be/9Pw7U0XFgUM At least I hope it's the correct one...

Happy New Year to all! I hope 2022 brings you good times and some fun new IOT projects! I just downloaded KiCad 6.0 as a present to myself, so I predict some new PCB designs are in my future for 2022 : )

@mfalkvidd - Sorry I didn't make it clear but I was thinking of doors, windows, blinds and curtains. Curtains don't usually have UP or DOWN, they are OPEN and CLOSED. Likewise with doors and windows which are normally OPEN or CLOSED. Only if V_ARMED is set true should it send a value of V_TRIPPED. But in normal circumstances they are OPEN or CLOSED (or maybe smoewhere inbetween, but V_PERCENTAGE handles that situation).

@skywatch my 50 cents is that you might want to achieve to much. Having 2 different networks is not a problem. But one device in 2 networks, not sure if it will solve your problem.

@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!

@virtualmkr That is useflul to know - thanks! - As it happens I think I had my first wdt 'kick' early this morning as the Gateway with the wdt on was showing as up for 3 hours instead of the 4 days I was expecting, so it restarted and all is still working

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.

@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.

@skywatch There is also the next "Yet another Arduino with fancy hardware but poor library support" planned: Arduino Nano RP2040 Connect

@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 tak og i lige måde

@Yveaux Makes sense now. Thanks again.

@Yveaux Thanks for the pointer, I will take a good look at that. What I need is something light that won't have a growing variable. I thought of using an array as the best option, but I will vertainly look at what you have found. Thank you!

Many thanks @electrik and @Yveaux , some moral support is often pivotal in getting things done! @Yveaux IDE 1.8.12 is now available and working fine on win10 x64 for me

@hek Thanks! Our posts crossed in the matrix! I even got this right on a previous sketch, but a lot has been going on for me lately and I am finding it difficult to concentrate on things.

@zboblamont Thanks for the advice. I don't really want to 'fit' anything as I hope to move next year so something portable that I attach when I use the hose and then bring back inside is all I need. For the time being I have ordered one of those cheap Chinese flow rate sensors and a couple of hozelock adapters to get started with. Then I can take it up a notch from there if I want. Good thing about water for plants is no need for chlorine. After many years of doing this none of plants have complained! - And they include kaffir lime, lemon, tangerine, olive, banana, palms, lemon grass , chillies etc....

@skywatch My pleasure

Wow! It is interesting! I did not know that this is possible, thanks guys, I'll try in the evening

@zboblamont Thank you! - I didn't know if it was possible to send as a float or not. Now it is working as expected -

I believe that this was all due to a loose connection.

@mfalkvidd Today it did some real testing with the actual setup (not a test node) and it is all working really well so far. I was expecting to have to use limit switches to detect up and down limits, with microswitches to provide emergency power cut out to the motors if it overran. I even considered timing the motion too (done this with Crestron systems and curtains in the past). But I have had two really great surprises...... The little stepper motors, when set within their comfort zone, are very precise. It looks like just counting steps is all that is required. The steppers draw just 77mA when opening the blind. This is such good news for me as solar powered blinds (with li-ion or lead acid battery) will last all year! Big thanks to you all for the hints and finding where I mis-understood. It won't be easy, but I will get there in the end.

You will get multiple messages, if the message arrives correctly but the hardware ACK doesn't. Do you have a repeater in between the sender and gateway? It could be that the repeater does receive the initial message (and the sensor gets a hardware ACK), but that never reaches the gateway because of a transmission error between the repeater and the gateway.

@skywatch Take a look at my pan tilt project. A stepper i.s.o. servo can easily be achieved. I would recommend to use the AccelStepper lib to have a smooth movement.

@alowhum Thank you for sharing this! - This looks like exactly the kind of thing I was trying to achieve. Hopefully I get some time at the weekend to test it out. Cheers!

@skywatch no, nothing has changed. Since you've read the existing threads you already have a good view of the confusion and complexity.

@dbemowsk Yes I use PLA, it is a PLA printer. I am getting better results on some things now. I still have a lot to learn about this, it is not as easy as I thought it would be, but I am making progress and that is good. Small upright prints are (like knobs) are fine, it is the sprawling prints with a thinner flat area that are the issue. Cleaning with IPA and using a rub of glue stick seems to help a lot, as has re-calibrating the extruder and re-leveling the bed. Does anyone know where to get the latest firmware for the finder plus? I can't see any download page on the FF web site.

@johnrob I have similar experience to yours with the boards. Probably all pro mini boards I have a chinese made and they are working fine. I think this is due to the fact that they have past quality control. When you buy components, that's different issue - there is a very poor quality control in my experience.

@yveaux Thank you - I always thought of 'chat' as a live session (when both parties were online chatting) and PM as a private email type communication. That was confusing me!

@skywatch That was a nasty one to find the rootcause for - how did you do it? I don't use BT on my 3B, so it's disabled so I feel I have been lucky not to dig for this rootcause

MQ are always a bad choice, saturate air around with any gas and they will react ... Mics are used by sensely, but even them aren ot calibrated... and they are a hell to get working even when you have the pins soldered to them.

This seems to work for anyone who needs it....... void receive(const MyMessage &message) { if (message.sensor == CHILD_ID_GETFORECAST && message.type == V_FORECAST) { forecast = (message.getString()); if (forecast == "stable"){ Index = 0;} else if (forecast == "sunny"){ Index = 1;} else if (forecast == "cloudy"){ Index = 2;} else if (forecast == "unstable"){ Index = 3;} else if (forecast == "thunderstorm"){ Index = 4;} else if (forecast == "unknown"){ Index = 5;} }

@skywatch Turns out that the Rpi 3B has a 'interesting' serial implementation. It seems that this was the issue with 99% of the problems I was experiencing.

@Nca78 That makes perfect sense! - Thanks for the clarification.....Onwards and upwards!

@hard-shovel Thanks for the response. The volume control is motorised so no need to 'remember' where it is as it is possible to manually change it and there is no feedback that could be used to determine changes. The remote control requires you to hold the volume buttons (+&-) down until desired volume level is achieved so I suppose I could start repeating the IRSend code from the node if one valid volune command is received. The first time the node gets a valid volume command it just repeates the send over and over until it gets another identical command which stops the loop. I'll think more about it and also see if the controller has something that might be suitable. Edit - Why not just start the volume repeating the code to go in whatever direction you want at a suitable speed and add a volume 'Stop' button - that would be easier! - I think I'll try that at the weekend...... Thanks again, I can finally start hiding all the remotes cluttering up the place!

@chisight Thanks for the idea, I'll keep it in mind but for this project some of the relays will be controlling lights etc, so minimum delay is desireable. Thanks.

Thanks for some interesting info! The reason is 1. To save memory for adding more sensors, signing etc and 2. To save battery energy on battery nodes. So there is likely more than one solution to this problem. Also, I have used 'for' loops as well and wonder how this affects memory and battery drain? Thanks

@Johhnywalter I don't have equipment to test this, sorry. I only wanted an indication of the level of dust in a bedroom. But for now I have shelved this as I have more ijmportant things to take care of.

Thanks for all the input and ideas - I'll go with cr2032 and see how it goes. Batteries, holders and ceramic caps are all on their way, so time will tell on this one. Thanks all!

@skywatch Thank you, and same to you.

@petr-nosek sure with the 2nd power supply it looks different. However mine were all in-wall and there is just not enough space for this.

@wallylama I already did that! - That's why I now need to make it all work!!!

@rejoe2 it is a feature currently mainly useful for gateways. Furthermore, only avr is supported, as far as I know. It has been in for over a year iirr.

Thank you all for taking the time to reply. I will take a look at the documentation, but then realised I could just have one controller at a time running to test at first (doh!)... - Still, this really is all about an end product that works for my needs with learning new stuff into the bargain. I'll let you know if I do need to try it - nice to know it's an option!

@skywatch the Arduino-based serial gateways are more proven. They have been around for a longer time so more people have tried them. But the Raspberry Pi gateway should work. May I suggest that you enable debug logging on the gateway using these instructions? You should then be able to get a clue in /var/log/syslog when/if the gateway stops working again.

And here is the info in boards.txt.... atmega328_1mhz_4800baud.name=Optiboot 5 for bare 328P, 1MHz internal clock, fast start, 1.8V BOD, 4800baud upload, c/o tim7 20130416 atmega328_1mhz_4800baud.upload.protocol=arduino atmega328_1mhz_4800baud.upload.maximum_size=32256 atmega328_1mhz_4800baud.upload.speed=4800 atmega328_1mhz_4800baud.bootloader.tool=arduino:avrdude atmega328_1mhz_4800baud.bootloader.low_fuses=0x42 atmega328_1mhz_4800baud.bootloader.high_fuses=0xde atmega328_1mhz_4800baud.bootloader.extended_fuses=0xfe atmega328_1mhz_4800baud.bootloader.path=atmega atmega328_1mhz_4800baud.bootloader.file=atmega328_1b.hex atmega328_1mhz_4800baud.bootloader.unlock_bits=0x3F atmega328_1mhz_4800baud.bootloader.lock_bits=0x2F atmega328_1mhz_4800baud.build.mcu=atmega328p atmega328_1mhz_4800baud.build.f_cpu=1000000L atmega328_1mhz_4800baud.build.core=arduino atmega328_1mhz_4800baud.build.variant=standard atmega328_1mhz_4800baud.upload.tool=arduino:avrdude```.

I tried it with a simple digital binary sketch and it worked as far as the display goes. I could get a graph so I could know at what time the lighting strikes were. Trouble is, no lightning to test it fully with

@skywatch I think you are confusing "secret" with "unknown".

All sorted now, a reboot of the pi was needed and it all started to happen automatically!

That worked previously because the MySensors class inherited RF24. In 1.5 you can initialise a radio driver which has a sleep method that calls powerDown() (in the RF24 case). The radio automatically wakes up when sending a new message.

I tried to see if I could edit my post to see what went wrong with the formatting, but could not see how. Maybe the 'How to ask for help' sticky should be updated. Anyway, there are 2 x AM2302 (DHT22) sensors as you so correctly noted. The door sensors are for future use and are not referenced in the code except as the commented out bit which reminds me to keep those pins free! gw.sendSketchInfo("EASYIOT_FgeFzr", "0.1"); gw.present(Fge, S_TEMP); gw.wait(SHORT_WAIT); gw.present(Fge, S_HUM); gw.wait(SHORT_WAIT); gw.present(Fzr, S_TEMP); gw.wait(SHORT_WAIT); gw.present(Fzr, S_HUM); gw.wait(SHORT_WAIT);'''' This is what I thought predented the sensors. Have I missed something obvious? Thank you for the reply. I appreciate the help.

I understand that this answer is a bit late, but for future reference if someone finds this thread, I think the best answer is at http://forum.mysensors.org/topic/838/windows-gui-controller-for-mysensors/73

I forgot to add that the pi zeros should not be on ethernet or wifi and therefore I would like to do it all via the NRF24L01+. It would probably be cheaper to use android tablets, but that would require wifi (unless anyone has attached a working nrf to a tablet?) and wifi is not that secure. I have a lot to learn before I get to that point though!