General Discussion

What is also most interesting with zigbee is a very important number of devices, and low price of them compared to zwave for instance.

In a previous house I had a wireless sensor that was cylindrical. I drilled a roughly 3/4" - 7/8" diameter hole in the doorframe and slide it in, so it wasn't at all visible when the door was closed. Because of the packaging and form factor, some exotic things, like that, are far easier to buy than build, though I suppose it would be within the grasp of someone with skills who was determined to make their own. Less exotic: if you made your sensor flat enough, you could hollow out the door molding and hide it inside of that. A properly designed door sensor could run off of a CR2032 coincell battery for 10+ years, so it's not such a wild idea.

@nrf24_is_hard When I sent data between an Aduino and the RPi I discovered that I have to make the the receiving and the sending structs the same size AND the variables be on 4 byte boundaries. Change your char name[15] to char name[16] Another challenge is that the number of bytes of type int are different. If I remember correctly, Arduino Uno is 2 bytes and RPi is 4 bytes. To make matters worse, some compilers make the least significant byte the first byte of a word and others make it the last byte of a word. eg, sending the value 1 would be received as 16777216 (0x00000001 vs 0x01000000) There are a lot more gotcha's ;) OSD

@NeverDie said in Bootloading a barebones arduino: You and a group of friends could sit around a table and pass bits and bytes to each other using an SPI communication protocol. Passing bits and bytes is probably more fun that sitting around a table and passing digs and barbs! I don't know: maybe my friends ARE binary!:angel: [Edit: I forgot to say anything about the content of your SPI protocol story. That was a great story; I feel badly for not thinking about the SPI connection at all. Now it is ingrained. ]

I just remembered the key technique to getting the communications working smoothly. I do all my communication synchronously. That is as follows: The master device sends a message to a node. The send command returns a success or fail, but fail does not mean the message was not received, it means that an ACK was not received. The master waits a timeout period for a response. If there is no response, a second attempt is made. If there is a response, the data with the response is processed. If not, the node is ignored. After that transaction, the master repeats this process with the next node and for each node there after. A round-robin. If a node does not get a request from the master within a certain interval, it reboots itself. If the system power cycles, the nodes inundate the the master with DHCP requests. Because of so many requests, requests can be ignored or two nodes might receive the same network address (different from NodeID). Eventually, one node will get a valid network address and begin to communicate as expected. This reduces the network traffic and the probability of another node receiving a unique network address improves. Eventually, all nodes connect. "Eventually" can be many, many minutes. The tree structure of the network means that some nodes send data through other nodes. In asynchronous communication, a node may be trying to send data while another node is sending data through it. I may not be correct in this, but I think that it is possible that this will corrupt one or both data packets. This is why I do the round-robin communication. The master only has 5 (4?) usable addresses to receive data. Like computer DHCP, addresses can be reserved for specific NodeID's. For example, address 3 an be reserved for NodeID 31, then NodeID 22 can have a reserved address of 43, thus NodeID 22 will always send data through NodeID 31. (addresses are octal). The address 4444 is reserved; this is the address a node requesting an address uses. To increase the chance of getting a valid address, I put a delay in the first DHCP request based upon the NodeID. I put the NodeID in EEPROM address 0, as does MySensors. I have one program that sets the NodeID and then my program for all of my nodes is the same. Nodes that sleep must have the flag set (in the node software) that indicates no data can be passed through it from another node. All of these hoops are handled by the MySensors libraries, though I force the NodeID. This my impetus to use MySensors. I must wonder though, "How much overhead is there? Do I have enough memory for my code?" So far I haven't had a problem. OSD

Small update. I switched to a radio from different batch and seemed like that fixed it. Saw the smart sleep message in mqtt until I went to bed. But around 4:30am it stopped again. Im going to go pull it again and see what it's outputting. I feel like I need to hook up a bluetooth hc-05 or something so i can just connect over bluetooth at this point to get the serial data lol

Yip Mecrisp Forth. I will also need to add software interrupt routines for the BLE SoC interface. c-:

@NeverDie Oh, sorry, I wasn't trying to get proof or anything. I just was asking for your personal experience. Not doubting, just looking at them now and wondering how it had been for you. Do you mind saying which one you have that you are so happy with? I've been looking at different 'best' lists, and getting some conflicting info on them. I'd just like a little more input before buying one, but with seeing all the improvements, and how many devices we have that could use it, now I'm wanting to do it sooner rather than later. Thanks!

@hek I see that MySensors logo is missing in the forum [image: mysensors-forum.png]

I even managed to solder a nRF24L01+ to the board so everything works on 3.3Volt, and this node works fine. This took a lot of scratching copper from the board... [image: 1651654060736-uno3vnrfs.jpg]

i'm to stupid for this

@ejlane Yeah. I did this a while ago and I will have to dig into my notes to figure it out. I don't recall how I combined the STM code with tekka's multiple transport (which i think was in the development branch already), but it was not much more than cut and paste. I have an NRF24 and an RFM69 running on one and an RFM95 on another. I can figure out the details when I get back home in May.

It would be great to see some improvements added to MySensors lib. Like a good message Queue and stuff like that. Ways to get more state out of the lib so you can provide a bit more user feedback. Right now I have some of those in my own lib. When I have time I'll post some on this forum. So others might benefit. But I'm currently hooked up to modular synths. Learning a lot of analog technology. Which broadens my Arduino horizon.

Hi there! Reading the Watermark sensor is no easy task indeed. Took us a while to get accurate and reliable data out of these sensors. First of all, take a look at the official documentation provided by Irrometer: https://www.irrometer.com/200ss.html Especially the pseudo-AC excitation is very important and make sure you calibrate the readings using the soil temperature. There's quite some off-the-shelf hardware on the market already. Look for a device that has a low power consumption so you can measure throughout the year, for example: https://www.crodeon.com/blogs/news/connecting-a-watermark-sensor-to-the-cloud Let me know if you have any more questions!

I've been using processing.org to capture data from Arduinos. I haven't tried with an RPi yet, but the link here is dedicated to just that. Processing is more geared for doing really fancy graphics, but its ability to capture data and put it to a file is great, and, of course, send data to the Arduino. I am inexperienced in interprocess communication, but, apparently processing can put the data out to MQTT check this link Let me know how that works out for you!

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

@A3V such a feature would definitely make sense now that gateways can have local sensors. But no-one has added it unfortunately. A solution could be to use the code at https://github.com/mysensors/MySensors/blob/2e00bf6a10f76d6aaa1999e12313237bc3edabd3/core/MyTransport.cpp#L446 as inspiration and do something similar at https://github.com/mysensors/MySensors/blob/2e00bf6a10f76d6aaa1999e12313237bc3edabd3/core/MyGatewayTransportEthernet.cpp#L175