Best posts made by ejlane

Just a warning upfront - I'm an engineer, but not an RF engineer, so I do see some things, but I'm almost guaranteed to miss others.

As far as your highlighted line, it is a trace, but not a via. A via connects the trace on one plane of copper with a trace on another plane.

That trace should really be as short and direct as possible. Wrapping around the back of the module and along other signal lines is not a good idea. I see that the closest line to it is 3.3V power, so that acts basically as ground for small signal, but any power spike is bound to couple into the antenna line as well, at least some. If possible, it would be best to have ground on both sides of the antenna trace on that side of the board, as well as the whole surface on the other side of the board from it. Might also want to guard it by having vias connect the ground planes on either side of it to make kind of a 3d cage around it.

Additionally, you should try for 50 ohm trace impedance on the antenna line. However, there is no one-size-fits-all answer for the width of this line. It depends on the exact board parameters, and even to a small amount on the frequency of the signal. There are trace width impedance calculators that you can use to get this answer. https://resources.pcb.cadence.com/blog/2019-just-how-wide-should-a-pcb-50-ohm-trace-width-be

Almost guaranteed that it's correct to ground those 4 outer pins of the antenna connector. View the datasheet of the specific connector you are using to be 100% sure.

I have a Nortek GoControl USBZB-1 zwave/zigbee hub. I've been very happy with it. I've mostly used cheap devices with it, and only maybe 2 more mainstream things, like a Philips light. Other than lights, I think I only have a bunch of these plugs around: https://smile.amazon.com/gp/product/B08L3K5KPB

Anything branded Zigbee is supposed to be certified to work with any Zigbee network, but I have no idea what the big names do on top of the protocol. I've also never used a name-brand bridge device, so I've never really looked into what it might need. Home Assistant knows that it's a Philips light connected to it, but that's because it asks the devices for their info, and things like brand and serial id get returned to it. Probably other stuff - it's been a while since I looked. Anyway, even though it knows all that about the light, it's just using the basic Zigbee driver for it through the USBZB-1 gateway, and it has full control and it all works fine. I'm pretty sure it's not sending out custom Philips commands to the light, but just standard stuff.

Hope that helped a little!

@NeverDie Yeah, but when I priced out domestic places, they all wanted enough that the client just decided to go a different way. This was only going to be for a prototype, but even so, I got prices ranging from I think $10-50 per pin holder, and it was less than 2 grams of plastic each. I just checked again, and JLCPCB would do them for $1 each, and then $20 for quick shipping, and as low as $4 for the slow boat that takes a month. None of those options were very appealing at the time.

Digikey wants $13.66 each for this when I pick qty 10, so still not worth it for this project. Shipping with them is free, but I have no idea how quick they would be.

I also checked PCBWay, just for fun, and they quoted 1.24 at qty 10, for $12.45 total. Interestingly, the quote for 1 was $12.45 also. They wouldn't show an estimate for shipping without clicking the 'Submit' button and having a human engineer review the file for printability. Since I'm not actually going to do this now, I don't want to waste their time, so I don't have a total price from them for comparison.

As far as OP, this is a very old thread from 3.5 years ago, so I doubt that they still need help.

Yes on the flyback diodes.

However, the upper transistors look like they're NPN, not PNP. The lower transistor would be PNP.

Otherwise, it looks like it would work, as long as all of the transistors are sized correctly for the current on the relay coils.

But I would be really hesitant to try to control that kind of power with an arduino. What happens if your code has an error and locks up? What if you have the magnetron running but not one of the heaters? I don't have answers, as I don't understand the working of them that well, but code errors running a high voltage radiator device like that make me a bit nervous.

I like being able to turn on the microwave and then ignore it and do other things while it's running, but it would take me a lot of watching it before I would feel comfortable with something like this.

On the other side, you're only controlling 3 relays, and it's not a nuclear reactor or anything, so I'm likely being overly cautious. But I am an engineer, and worrying about "what-if" is kind of my job, so I lean that way anyway...

I think your numbers look good. Nice job getting the trace much shorter - that should help a bunch.

@NeverDie said in Which vector network analyzer should we buy?:

It said version 2 was due in January.

It looks to me like it's available now. After where it mentions the 2.0, there's a link where it says 'authorized dealer.'

That link goes here: https://www.tindie.com/products/hcxqsgroup/nanovna-v2/

And it says you can buy it now for a little under $60 US.

I don't know anything else about it, but I'm also considering getting one, now that I've read about it in this thread. I like the idea.

I wouldn't even bother with an Arduino/microcontroller at all for this. Just some diodes on each circuit and maybe some transistors for powering the large LED strips, or could also use tiny relays.

But I don't see where it has anything nearly complicated enough to have code running on a chip to run anything on it. @itjobhunter if this is not helpful and you need more specific details and/or a quick napkin sketch I can throw something together to show what I'm trying to say.

At least here where I am - West coast of US - they're allowed +/- 10% and still be counted as within spec. So those numbers are fine.

The thing is, they have voltage transformers with multiple contacts inside, and they will step the voltage up or down on the neighborhood feeders as necessary to account for varying voltages on the higher voltage lines. Actually, I think the switching happens going from high to medium voltage, and there aren't really that many of the switching transformers in the system. All of your local transformers for the houses wouldn't have them - that would be far too spendy. They do it on a large scale.

But as the residential power demands change over the day, they use the switchers to keep everything balanced. They could keep the voltage variance smaller, but at the cost of more frequent switching, and every switch of the contacts creates some wear, so more maintenance eventually. Every switch also creates some ripples in the rest of the system, I'm pretty sure. But those are probably pretty minor - it's a very stiff system. Also having higher resolution on the switchers would be more complicated and have more parts/windings inside every one of them. They keep the frequency very tightly regulated, but allow the voltage to float a bit. The frequency variances they have to make up for throughout the day so that over the course of a whole day there's practically no net change at all. (For the sake of clocks that literally count cycles and therefore don't need a crystal.)

Actually, allowing the voltage to vary also has another nice benefit to the system - it allows for a natural damping of disturbances. When the voltage dips a bit because of increased demand, the power used by many resistive appliances will also dip, so that can help the system in recovering as potentially more generation is brought online. I don't think something like AC that has a spinning motor helps much, as the frequency won't vary much.

Sorry if you're aware of most of this. I worked for the power company for a while, though that has been some years ago now.

@kasparsd Yes, this is a very disheartening thing to see.

I would rather not have to maintain a local version with some of the fixes that I see talked about on the forums, but since there's no movement on the code, at least from looking at github, I'm left with doing a bunch of it myself if I want to incorporate the changes.

Especially bad when the changes are in a pull request and just languishing there. It's discouraging when I want to go work on something but I need to deal with the core mysensors code before I can even get to that step.

I mean, I'll deal with it cause I still appreciate mysensors and find it a net benefit, but I can certainly understand why some people either give up on it or maybe never pick it up in the first place, seeing stuff like that.

@NeverDie As far as when the shortage ends, ??? I've seen estimates different times that it's "right around the corner" but nothing that was very convincing to me. Intel just this week or last came out and said that they think it's going to be better soon. NVidia chips/cards are getting to be more available. And random different chips have re-appeared, so maybe they're right this time? I wouldn't bet on it, though. There are still tons of parts that are hard or impossible to get in any quantity. I'm no insider, though. I shop at Digikey, Mouser, etc. same as you. Just maybe more often and a bit higher qty sometimes.

I actually have some of the Attiny3226 here to play with. When they came into stock, I bought a small bag of them. I haven't yet had a chance to do anything with them, though. I do see power consumption tables. pg 477-478 of the datasheet. https://www.mouser.com/datasheet/2/268/ATtiny3224_3226_3227_Data_Sheet_DS40002345B-2887812.pdf Numbers seem pretty reasonable, for a claimed 'low power' family of chips.

@NeverDie I've only done my own panelization maybe 2 or 3 times ever. Usually just leave it to the board house, but 10 or so years ago, before the board houses were quite this cheap and I was on more of a budget because of saving for a down payment, I did try it out for some personal projects as an experiment.

But I didn't even try to do v-grooves. Not sure if whichever one I was using would even allow it. I just left extra room between the active parts of the board on the PCB and literally took tin snips and cut them apart with that. With 1 cm between boards it's easy to not hit anything.

Obviously doing it like that wouldn't weaken their board, but if you need precise board shape/size then this wouldn't do it. Ever since then the prices have gotten so low that I don't bother trying. I would be interested knowing what about JLCPCB's process makes them want to limit any order to the 30 pieces. That's always seemed a bit weird to me. I would think they would welcome the extra volume/money.

But weirdly enough, I don't even know where to go for larger orders. I mean, I can do a search like anyone else, but I don't have direct experience. By the time it gets to that qty, then the assembly house deals directly with whoever they work with to get the boards made. At that point it's not me dealing with them directly, except for passing requirements to the client, who then passes them to the assembly house, etc.

I've also entered some of their limitations into KiCad, but I'm not sure if I did a complete job of it. I try to be a bit more conservative than being right at the manufacturable edge. But yeah, get the rules to catch as much as possible. I think my problems came in when I did something that such a minor change I didn't even really think about running the rules again, and of course something like that is usually harmless, but every once in a while it does something unexpected, so obviously the rules need to be checked after every change, and every time before exporting gerbers for manufacturing. And I try to do that, but still these days I'm sure that are times that I forget.

@NeverDie My personal preference is the Tag-Connect. It costs a bit upfront to get into it, but then there's zero ongoing BOM cost per board, and the connectors are very sturdy, so I don't get bad connections, even while doing extended troubleshooting.

Of course, if I hadn't needed them for a customer project, I might never have sprung for the upfront cost, as the cables are somewhat spendy for the what they are. But they are very well made, and have been great for me. The board footprint is pretty tiny, so that has yet to have ever been an issue in my projects. The footprint is also keyed, so you can't put the cable on backwards. Always a good thing. Also, since the connection points are not through-holes, you still have the back and interior of the board for routing traces. Of course the alignment pins are still through-hole. I prefer the type without the locking pins, and then there's a little board that you slide on the alignment pins from the back to hold everything together.

If I were to go with a standard, I wouldn't be excited about his ESP Flash one, simply because I don't see a need for it. Yet another 'standard' just fragments things worse. I would use the ESP-Prog one if needed, and use the .05" pins if I needed tiny.

Yes, that does look nice, and I'm going to have to think about doing something similar. Water leak can really ruin your day!

However, how can you just casually mention "home made smart speakers" without giving more detail??? That's what I want to hear about!

I was about ready to make a bunch of them using snips.ai and was even starting on 3d printing enclosures when they announced that it was being taken over and was no longer available.

I still plan to do it, but I haven't been able to make the time yet, and I haven't settled on which setup to use instead of snips. Though most likely is Project Alice, which is kind of/sort of an open source fork of snips. (With a lot less polish. We'll see how it goes.)

I know this an old topic now, and I don't know if this would still help you @otousset, but I ended up running across this while searching for a solution, as I had the same problem. I finally found the solution at this page: https://docs.platformio.org/en/latest/platforms/ststm32.html

What it comes down to is that there are two different 'Arduino' cores with platformio, and we have to use the 'maple' one, which has the libraries in the format that the MySensors expects to see. The line:
board_build.core = maple
has to be added to the platformio.ini file in the project folder, which switches the core to be what MySensors framework needs. Then I got it to compile without complaint. (Well, but I guess I haven't actually finished my installation to be sure that it works with the gateway...)

@NeverDie I tried to combine shipping and try out their 3d service a few weeks ago, and they said something like 'incompatible' when trying to combine the shipping. They would only ship the 3d print separately from the boards. And I was only trying to print some little pin holders, so it wasn't like it was something large and unwieldy, or even really delicate. Just a basic small part.

So anyway, don't count on being able to combine shipping. I ended up not having them do it, so I don't know how their 3d print quality is. I might still end up trying it just to see, but I have my own printer, so it's not a rush.

I'm an engineer, though not RF. My understanding, from short discussions years ago with RF engineers, was that the ground planes have strong effects on antenna performance.

Depending on the design of the antenna, sometimes you want the ground plane and sometimes you don't.

But that's the extent of what I remember. (And it could be that I've even got errors in that little bit.) But basically to go with whatever the antenna designer recommended, because there are reasons for it. Just because one design calls for it and the other doesn't, it doesn't make either of them wrong.

Without the deep understanding myself, and not having however much testing equipment necessary to check the results, I try to stick as close to what the manufacturer/designer calls for as possible.

@CrankyCoder Rhasspy is a good one to add to my list!

I've seen the name before, but I suspect I thought it was tied to something else? For some reason I've never looked deeper into it. That was a silly oversight on my part. Thanks for the clue!

Would you mind adding your experiences to the Smart Speaker topic that I started? It would be great to hear from another user direct feedback on what that system is like! (And I would like to keep from driving this topic too much off into the weeds. )

@mfalkvidd Oh, that kind of issue didn't even occur to me. I was thinking that it was still showing up as the same mysensors network, but that now what used to be sensor 10 was now 3 or whatever.

Yeah, my suggestion wouldn't help if Home Assistant sees this as a totally new connection/profile/whatever.

And I use Home Assistant, and I've changed gateways, but I'm always tinkering, so I change things often, and it was no big deal for what I do to go from one to the other. I don't remember having any issues with this. (Could be I still did, but it was a minor enough problem, compared to other big issues, that I simply forgot about it.)

But I don't have an easy way to test going from one to the other right now. I don't have a spare gateway to test on.

Sorry about all the replies, but I just remembered one more thing. I was using the current version of MySensors, but I also then switched to the development branch, just to see if it changed anything, but that also didn't do any good. (Didn't do any harm, either.)

@NeverDie Probably not every chip, but a huge ton of them. STM32 chips and STM8.

You can also set the framework to something other than Arduino, but of course then MySensors won't work.

In fact, I had to add a build option to make Platform.io use the Maple core, because that was the only one that would work with MySensors. (At least that's what I found at the time.) I don't remember what the default was if you don't specify which core to use, but I was getting some weird errors at compile time from MySensors. I might even have posted about them here somewhere.

This was the option, at the end of my platformio.ini file:
board_build.core = maple

And even though platform.io supports building for STM8 with Arduino, I never tried one for MySensors, so I have no idea if it would even work. I just included the list of them to show how much support platform.io has these days. I'm not sure one of the STM8 chips would even have enough flash space for MySensors, nor whether they support all the same instructions.

Anyway, once you get the settings right, it just works and I'm very happy with it. My sensors are a mix of NRF51822, STM32, and Atmega328 and they all are easily programmable with platform.io. (Though I still don't have much beyond the testing stage, as I keep changing large things like whether my gateway will be serial or mqtt...)

Yes, lower frequencies are better for going longer distances and penetrating walls, etc. I also would not try the NRF radios. 2.4GHz almost certainly won't do it.

The 433MHz RFM69 might do it, but I would be a bit surprised. I think your best shot is to try a LoRa module, so the RFM95 might do it.

If it doesn't work right away with just the boards and basic antennas, it's always possible to get better range with a good setup of directional antennas. In fact, sometimes having the right antenna is almost more important than the radio. (Not really, but it is super important.)

Well, I guess I'm just talking to myself. I must be the only one running into this right now.

I did manage to fix it, but it's a bit of an ugly way to do it. I've compared the code for different frameworks in platformio, and I haven't really figured out why it fails on STM32, but not the others I've tried. No, I haven't exhaustively tried them all.

In the .platforio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp file it's really almost completely empty. But then, so is the one from MySensors, though it has one addition for serialEventRun. Interestingly, other frameworks through platformio have this line as well, just not this one.

Anyway, the MySensors one has that extra, so I commented out the maple one through platforio, and then it lets the compilation complete. I haven't gotten far enough to know for sure that it doesn't cause further problems down the line, but I hope this is progress, and I wanted to get it written down while it's still fresh in my mind.

@mfalkvidd In looking at the files touched, it does look like that pull request is attempting to support all of STM32. I have no idea if it will work, but at least from the people that have replied to the conversation, it at least looks like it should work.

Though I'm a little concerned by a couple of the include orders. Here: https://github.com/mysensors/MySensors/pull/1422/files
In MySensors.h, at line 71 the STM32 arch is checked for first, but at line 450, the STM32F1 arch is checked first. This would only be a problem if they were both #defined, but I could see that being possible, though unlikely to be common. I think the more specific F1 one should be checked first both places, and then only fall back to generic ST32 if that fails.

I also see that some of the hardware features are disabled, like the CPU temp, voltage, and the random number generation looks vastly simplified/maybe weakened? However, all of those things might have been necessary to keep from having to write individual code for each chip line. If so, that sounds like a decent trade-off for being able to work with so many more chips.

Also looks like the only transport support is for the RFM69, where once again the STM32 arch is checked before the STM32F1.

Overall, I would say that if this pull really supports a bunch of STM32 chips (and passes tests) then it's a good addition, but it looks like it needs work to really be complete.

Well, it could be that the issue is the voltage regulator on the Arduino board. The higher the input voltage, the more power/heat that needs to be burnt at the voltage regulator. Maybe it's self-limiting because it's getting too hot?

The Arduino website lists this part as the voltage regulator:
https://www.mouser.com/datasheet/2/146/SPX1117-1889129.pdf

On page 6 it claims a thermal resistance to ambient of 46 degrees/W. If you're using 1A and have 12V input then you're dropping 7W across the regulator. This is a temp rise at the junction of 322 degrees over ambient, which it obviously won't do. The datasheet also says that it's internally regulated and will current limit at 155C. Assuming 25C ambient, this only leaves a margin of ~2.8W that can be dropped over the regulator. So you'd have problems with any more than around 400mA. To have a safety margin, I wouldn't plan on more than 300mA or so, or maybe even down more towards 200.

This voltage regulator is a nice, low dropout one, so if you could power it from a supply that gave it 6 or 7V instead of the 12 that would give you a ton more thermal margin and the regulator could then allow a lot more current through.

Hello everyone,

This isn't exactly troubleshooting, but it seemed to fit in this category best. I've built a dual-radio gateway on a Raspberry Pi Zero as on here: https://www.openhardware.io/view/470/MySensors-Gateway-for-Raspberry-PI

I compile the software twice, once for each radio, and that all works just fine. However, I can't seem to get Home Assistant to use two different mqtt gateways. Is that just impossible? The Mqtt broker is on the same Raspberry Pi as the Home Assistant, which is on a RPi 3. If I have two entries in the configuration.yaml file, then it only seems to ever acknowledge one of them.

I'm open to switching away from mqtt, but it looked like it might be the best fit. My main desires are to keep the communication between the gateway and Home Assistant only on wires, so they are both on my ethernet network. I'm actually also open to modifying things so that everything is done only on the RPi 3. (That might actually be preferable, but since most things don't expect that, I didn't want to introduce extra unnecessary effort.) I'm using hassio right now, I think, so modifying or getting sudo/CLI access might be an issue.

Now, my main reason for wanting dual radios is that I want to use the RFM69 for it's lower frequency/longer range, as well as hardware encryption for all of my outdoor sensors. (Mainly garden stuff, at least for now.) My indoor things are going to be based on the nrf51. It seems plenty powerful, and is available in cheap modules with all the pins broken out. What I really don't want is for there to be any way for an outdoor sensor to masquerade as an indoor one. Like if there's something on my garage door, absolutely nothing that the outdoor sensor every sends should be possible to trigger the door to open. I thought having there be two sensor nets, and having them be separate by external/internal would be good safety, and keep physical access to the radios an impossibility as far as hacking the protocol for the indoor ones.

This way I don't have to worry if an outdoor one ever disappears, because worst case is it could turn on a sprinkler or lie about some plants being dry, etc. I mean, it's not like I have much valuable here that anyone is going to go to great efforts to hack into things, but I just don't like the idea of leaving things lying around that could wreak havoc if someone knew what they were doing. I'll sleep better this way.

Okay, so with that in mind, am I going about this the right way? I am open to writing a script that checks every incoming message from the outdoor radio gateway to ensure that only the whitelisted messages get passed along to Home Assistant. I just don't know enough about how any of the gateways are integrated into Home Assistant to have any idea whether I'm going about this in a good way or not. I don't really care what transport is used between the gateway and Home Assistant, other than it should be on a wire. Maybe something like what I want, or at least pieces of it, have already been thought of by someone else and they're already part of the system, but I'm just doing things wrong?

Thank you!

@NeverDie The characteristic impedance of the coax is what matters. And that is all determined by the construction, which includes the thickness, but also other things, like what dielectric, and probably even what metal is used. (I don't know all the variables that they have to play with.)

So it could be that both of those options you posted are fine. But buying stuff like this on Amazon, especially through third parties is a crap shoot. No telling if it will be good or not, and the reviews aren't usually very helpful, either, on RF stuff. Not saying you shouldn't do it - I will gamble myself, but just go in fully aware that your chances of getting something shoddy are good, and make sure the price you pay is worth the gamble.

Well, this is not super on-topic for the site, but there's probably a lot of cross-over interest with people here on doing a local smart speaker.

It came up in another thread with @KevinT, but was really not the topic of that thread, so I'm starting this one to have a better place to hold the discussion.

So the current "smart speakers" of yours are really just output devices? Is the MQTT to speech internal to the phone, or does something else do that?

I'd definitely be interested in continuing the discussion. Kind of off topic for this whole site, since its use of MySensors would be minimal. There would be a two-way integration, but it wouldn't be very tightly coupled.

My thought was a raspberry pi, or even a powerful server if needed for the speech recognition and also for responses, and then just raspberry pi zeros for the satellite devices. (They would be doing wake word detection and then simply passing audio back and forth, so not a lot of power needed here.) It would be able to be a pretty cheap overall solution, while keeping full privacy because everything would be done here at the house, not sent out to the cloud.

I'm going to add links here to what I think are relevant projects.

https://snips.ai/ is what got me started on the idea and general architecture, but they got bought out and shut down before I could really get my whole plan off the ground. I was still fighting the learning curve and only had a single device kind-of working like I wanted when the announcement was made. Their website now is just a landing page that points to sonos, so it's useless. Used to be that you could still view the old info there for a while.

Project Alice is an open-source fork of what was snips. Snips had been mostly open-source, with the large exception of their web-configurator tool. Project Alice is not a finished product, but it looks like it's in a useable state, though it also looks like it's mostly the passion project of a single developer. I think this is the way that I'm going to go, once I get enough free time to wrap my mind around it all. https://github.com/project-alice-assistant/ProjectAlice https://community.projectalice.io/

Then there's Mycroft. https://mycroft.ai/ It looks reasonably good for a front-end, but they use Google on the speech recognition. At least they realize the privacy downside of this, and they aggregate everyone's speech snippets and proxy it through their own server, so that minimizes the amount of info that Google could get out of it. They have been supporting Mozilla's Deep Speech project, but I don't think that you can send requests to that over the cloud. Though they also say that if you have hardware with enough power to run the Mozilla service locally that you can set it to do that. https://mycroft-ai.gitbook.io/docs/using-mycroft-ai/customizations/stt-engine#default-engine

While Mycroft will run on a Raspberry Pi, it needs to be a larger, more powerful one. It can't just run on a zero. https://mycroft-ai.gitbook.io/docs/using-mycroft-ai/get-mycroft/linux#system-requirements Although, now that the Zero 2 has come out, it might be enough.

Finally, just to be complete, there was the Jasper project. https://jasperproject.github.io/ I was especially interested in this one when it came out, both because it ran on a Raspberry Pi and my son is named Jasper. I thought that would be cool. It seemed like a great start, but then it died off pretty quickly. I got the feel like it was a student project and the students then were done with school and it didn't go anywhere.

That could be totally false - I didn't follow it closely. But it's been basically abandoned for quite a few years now. I didn't understand the code well enough to just pick it up and run with it, so I never did anything other than read up on it every year or two.

So that's my list for now. If nothing else, it's nice to have this all in one place for future reference. Right now I still think I'll end up going with Project Alice, but with how long it takes me to get to these things it might be a long time before I actually get anything going. If anyone else has suggestions, or things that I've missed, I'd love to hear about them!

@electrik Hmmm, that looks very similar to how I had my first configuration. Unfortunately, I've tried a few different things since then, so I'm not sure. I will have to sit down and try getting that all set up again and see what happens.

Once I've done that, I can share the configuration and details of error messages, if any. Maybe I just did something stupid.

But in trying all that and the reading I did afterwards, it looked like Home Assistant would only accept a single mqtt connection/gateway, so I thought that my config was overwriting the settings by having two entries, so I changed it to both go to a single one. Thank you for letting me know otherwise!

@NeverDie I think you've pretty much covered it. Yes, sometimes there's no good hobby-level alternative to Amazon/Aliexpress if you want it cheap.

Though someplace like SparkFun or Adafruit can be good for hobbyists, though you'll pay for it.

Along with Mouser and Digikey, sometimes I have good luck with Arrow or Newark. But really, it's nice to do a search with octopart.com or findchips.com if you have a pretty good idea of what you want. They will look at lots of vendors, even some that might be shading towards gray market. Can really save some time, and sometimes find things that I never would have otherwise. Saved me a few months ago on a customer project that would have otherwise had to be completely redesigned.

I'm not really familiar with FHEM, but as far as the MySensors side, you still need the gateway software running. However, this code can run directly on a Raspberry Pi, at least with a radio network for the MySensors transport. I haven't ever used RS485 myself, but I would think it would be similar.

At least the code itself has sections for dealing with running on Linux, which is what is used when running it on the RPi, so I think you're good. https://github.com/mysensors/MySensors/blob/master/hal/transport/RS485/MyTransportRS485.cpp

The gateway code runs as a systemctl service, so it can easily run in parallel with most things, so probably wouldn't conflict with FHEM on the same device.

Oh yeah, and in case you haven't found it, there's this page: https://www.mysensors.org/build/rs485

@mfalkvidd
I went ahead and tried it. But right now I only have one running at a time, so they shouldn't be able to interfere, should they? (I haven't done the 'make install' on either one, I'm just running them manually while I test things out.)

Anyway, no difference. I tried setting anonymous to true in the Mosquitto broker settings, and that allowed me to then connect. Now I have a new error:

Sep 14 14:19:01 DEBUG GWT:RMQ:CONNECTING...
Sep 14 14:19:01 DEBUG connected to 192.168.0.49
Sep 14 14:19:01 DEBUG GWT:RMQ:OK
Sep 14 14:19:01 DEBUG GWT:TPS:TOPIC=myIndoorGateway-out/0/255/0/0/18,MSG SENT
Sep 14 14:19:01 DEBUG !MCO:PRO:RC=1
Sep 14 14:19:01 DEBUG !MCO:PRO:RC=1

According to the log parser, https://www.mysensors.org/build/parser?log=!MCO%3APRO%3ARC%3D1 this is a recursive call. So I still have something wrong.

I'll keep working on that. But it now looks like my issues are primarily not a mysensors thing, and some kind of problem where Mosquitto is not accepting the username/password combo that it should be.

Can anyone share their settings for that, from the Mosquitto settings page of Home Assistant? Maybe I have a formatting or spelling error in there.

@NeverDie Haven't you heard of the chip shortage? It's changed everything, and prices for those things that are even available have generally gone up. (Though somehow magically, the ESP32 seems to be pretty much untouched. You can still buy them, and prices have been relatively stable. I don't know how they've done it.) AVR, PIC, STM chips have all been hard to get specific models, and at times any model that has the features. I expect other brands were similar, but those are the ones that I've looked for.

I hope they someday go back, but for the foreseeable future, expect it to be like this.

Pro minis for close to $1 was always a shock, since even at 1k qty, just the chip itself costs more than that. So to get to that price for the whole assembled board, there must be some kind of gray-market thing going on. If I were to try to make a profit on 1k at a time, assembled and everything, I'm pretty sure the final price would have to be in the ballpark of $10 each.

I haven't used that one, but here: https://www.elecrow.com/water-proof-integrated-ultrasonic-ranging-module-jsnsr04t-p-1151.html it says that 450cm is the max range, so you're aactually getting better than specified, by a good margin.

But with the ESP32 I don't know why it would go down in voltage, though I have a suspicion.

But are you really seeing those kinds of voltages and those aren't typos? I have some of the non-waterproof versions of the sensor, but I've never checked their voltages on the board. It just surprises me that they would have that much boost on-board. That could be quite a safety hazard if someone were to touch the wrong part.

However, what voltage input does the STM8S003F3P6 board run at? I see that it can handle up to 5.5V, where the ESP32 is strictly lower. If the STM8S003F3P6 board is about 5V while the ESP32 is about 3.3V, that's pretty close to the same ratio difference between the output voltages that you're seeing.

If that's the case then you just need to run the sensor at the higher voltage, and deal with level shifting the I/O. Though I saw mention of triggering the board with only 2.5V, so you might only need to worry about putting a voltage divider on the output of the sensor and calling it good.

@electrik

Looks like you're completely correct.

I don't know if I've ever used that function to manually add something to the dashboard, or if it was only long enough ago that I don't remember doing it that way. When I saw that warning about it not being editable, I thought that was an issue that I needed to address. (To me, it sounded like I wouldn't be able to turn a light on or off, for example.)

However, if that is not needed, then I guess I'm set! Now all I need to do is compare my code to the example code and make modifications where necessary to make mine show up.

Thank you so much!!!

@NeverDie Yeah, I think they are the next gen device. I believe that this batch that came out in the past ~6 months was the first production run of the '2' series devices. At least it was the first time that I had seen them available, though it wasn't something I had been actively searching for.

Should be about an identical AVR instruction set, but some of the low level stuff like registers might have changed, so it might take a bit of work to convert projects to it. I haven't done it yet to know.

Your voltage divider math is wrong. It should be of the form

R1/(R1+R2)

However, why even bother with a voltage divider? The analog inputs on the atmega328 can handle the full battery voltage from either of your scenarios.

Although, maybe you have the pin wrong? Or your setting of which board you are using is linking in a different connection? I don't know if the PDIP package would cause it to be a different pin. (I find that hard to believe, but I don't know what else to say.) Cause the reading should obviously change if you're really changing the voltage at the pin that you're reading... Maybe if you can feed direct voltage to the pin temporarily and see if it does anything?

Oh, and Skywatch's tips are also good. Solid power is very important. I would put a few different capacitors as close to the power pin of the radio module as possible. 100n, and then a selection from: 1u, 4.7u, and 10u. I would likely go with 2 of those microfarad capacitors, and maybe all three. I like to err on the side of overkill where power capacitors are involved.

@NeverDie I think that usually you can 'rescue' the symbols and part footprints from the files directly as well. I've had it successfully work usually, but a couple times when opening an old file from a previous KiCad version I've had some errors.

Knock on wood, but so far nothing has been unrecoverable. Of course having a dedicated symbol and footprint library would make it even more foolproof, but it might not be necessary.

@igo But in your code you have the wrong calculation. You have (R1+R2)/R2. Whether the names are right or wrong, that calculation is wrong.

But yes, I agree that it is not the root problem, that's why I also talked about trying to find it by checking pin definitions and putting voltage right on the pin.

But what @JeeLet said looks like it's worth checking. Maybe you need to try a loop of a bunch more reads to see if it improves after a bit.

@perIpI I don't know if this will be helpful - I haven't used an ESP8266 on MySensors, nor have I really messed with one hardly at all.

But when I was troubleshooting my NRF51822 with MySensors, I was surprised that there were two different baud rates. I had MY_DEBUG enabled, and during the library initialization and waiting for the controller to hand out an ID it had one speed, while during normal use it had another. (I had other issues, so this took a while to resolve.) I also had Serial.begin(9600) but during startup it ran at 115200. Once it got to my code it then switched to 9600 and ran the rest of the time at that speed.

So all of that is to say that it's possible that if you let it run until you stop seeing responses at the faster 74880 speed, you might then get some results by switching and watching it at 9600. (Of course if you've already tried that then this won't help.)

Alternatively, you could simply switch the speed in your code to match the 74880 speed that you're seeing results at, and maybe you'll then see everything in the same window.

@NeverDie They claim that it is already available in a QFN16 package. https://www.iis.fraunhofer.de/en/ff/sse/ic-design/rf-ic/wakeup.html

But they say you have to go through "EBV Chips" to get it, and everything I've seen makes it look like that's for large companies only. I can get to this page at Avnet, https://www.avnet.com/wps/portal/ebv/solutions/ebvchips/ebvchips-overview/ but I can't seem to get past it to any chance to order or see a detailed datasheet or anything like that. A search just on regular Avnet for the part turns up empty with the things I can think of.

This is the best page I can come up with: https://www.avnet.com/wps/portal/ebv/solutions/ebvchips/rficient/ which is cool and all, but still nothing orderable for normal people.

@gulsimsur Why are there links to surveyzop in your reply?

Well, I've narrowed it down.

I got rid of all the testing code that was in that sketch, along with its associated uses of the serial port. (And for some reason at points it used Serial, but others used SerialUSB.) I don't need to have it test the AtSHA204 or the SD card every time it boots - I don't even plan to use those. I guess my plans can change, but at least for now, they just aren't needed.

But getting rid of those took care of the problem! So now I have a working gateway working just like I want it to, and I'm probably not going to do any further work on figuring this out unless someone else has questions and I can help them with it. For my own needs it's now done.

@OldSurferDude It looks like your gateway is set to send to the wrong topic? In the debug log it looks like the gateway is sending to the 'out' topic, while you mentioned that that was output from mysensors. But in your text you said you had it set the other way, so ??

I don't have a system set up with MQTT now. I used it for a while, but got tired of having to remember to update the RPi that was doing the gateway work. I kept letting it get way out of date and that's a bit of a security issue. So I switched to a serial port connection that's powered by the HA server and plugged into a USB port from it.

But have you used the log parser? https://www.mysensors.org/build/parser

It can help a ton with understanding all the messages that you're getting.

But double check your topic settings is the only idea I have right now after seeing those log messages. It looks like the gateway sent to the 'out' topic, rather than just listening to it.

@Larson While I definitely agree about the importance of using plenty of flux - it's almost magic - another very important tool is to have plenty of desoldering braid around. It's super cheap, and along with plenty of flux it makes it easy to clean up excess solder on the board or bridging between two pins, or whatever.

That combination will let you solder all kinds of things that otherwise look very daunting.

@epierre Yay, good job!

@Larson Yeah, I think of "No Clean" as really being "easier to clean." There's still some residue with those that I have tried, but they really are easier to clean up after than the regular flux.

So I still prefer them, but I don't like to leave them uncleaned. Maybe the residue isn't corrosive like regular flux? At any rate I don't trust it either.

Try using the Neopixel library.

https://learn.adafruit.com/adafruit-neopixel-uberguide/arduino-library-use

https://sbaronda.com/2020/09/20/sk6812-with-arduino-using-neopixel-library/

Those should get you started. Basically, instead of having your code directly turn a pin on or off, you tell it to set a color in the library and then run the show() command and the library will do all the pin toggling needed to actually control the LEDs.

@NeverDie Yes, though sometimes you have to dig a bit on their site to find them. Here's the one for use with the 6 pin tag-connect: https://www.tag-connect.com/product/tc2030-retaining-clip-board-3-pack

They don't automatically come with the cables, which could be a pain if you didn't know to add them to the order. Though this way I guess if they wear out it's easy to just buy the one without the other...

I think capacitors with a blocking diode would be the right call. How long does it need to supply power to the Arduino for? And are you running anything else off of this, or only the Arduino?

Basically, knowing how much power draw (current) that you need, and how long you need it for, and then also how much of a voltage droop is acceptable will tell you how big the capacitors need to be. I'm going to use a bunch of round numbers for easy math, but hopefully you can see how to adapt for your project.

Let's say you're at 5V, and you're drawing 100mA (a lot for just an Arduino, but not so much if you're also running LEDs and a radio, or a servo, or whatever).

If the voltage droop from the batteries due to the motors spinning up lasts for 1 second, then we just need to calculate how much charge that is, and how big the capacitor needs to be to keep it within a certain range.

The total charge, in Coulombs, is 100mA x 1 second = 100mC.

The voltage on a capacitor is: V = charge (in Coulombs) / capacitance (in Farads)

So say you want the voltage drop on the capacitor to be less than 0.5V. Then that's 10% of the initial voltage, so 10x on the capacitor (1/10%) gives you the ballpark. Which means 1F capacitor should be the ballpark you need.

Of course there's simplifications here. (And it's been a while since I did this formally - hopefully I didn't make any big mistakes.) Also real capacitors will not act the same as an ideal one, and tolerances on capacitors are HUGE. Of course the real voltage drop is an exponential, and the current draw will also have part that changes with voltage, but not the same as a resistor, so it would take a bunch of math to calculate exactly.

However, if you can get a ballpark answer and then double it or so, for tolerances, you'll probably be good enough. Heck, for a hobby level project maybe simply going 10x for a few pennies more would be a good idea.

@qqlapraline Those are some quick times for assembly! I usually am doing a board with parts they don't stock, so I have only used them for assembly a few times, and not recently, so it's good to hear.

@NeverDie I've used JLCPCB a bunch of times now, and I have yet to find an error that affected the board electrically. I've found small things like sloppy printing or some rough edges of the copper, but always small, and like I said, it has yet to cause an issue for me. For prototyping they're really hard to beat.

@NeverDie I've never done a LoRa project, but I remember reading somewhere that some packets can take multiple seconds! So yeah, that would take a very large capacitor. I'm not sure what I would do in that scenario. I'd have to give it some thought, but I also might go with a dedicated power supply that could just handle the full current. Of course it would also depend on the specific trade-offs that were best for that project. Interesting problem.

Are you sure about JLCPCB not working on weekends? I 95% sure that I've submitted designs on Saturdays before and gotten a reply that they were accepted later that same day. I've also once or twice gotten things rejected when I made a silly mistake that they caught. I'm sure that it's a person reviewing things, and they have caught a couple errors. (Not in logic, obviously, but I had done a quick change one time, and a trace on another part of the board also got moved somehow, and it crossed over another. That's the only one I remember what the problem was.)

However, you can also always add boards to an order that is in process and they'll ship together for one price. Though if you're adding enough boards then there will be a bit of a shipping differential to pay for.

Those sound like some fun tests, and I look forward to hearing the results!

@NeverDie Okay, sounds like you know more than I do about it, I guess. I was sure that I had gotten responses/work done on a weekend, but maybe my memory is just faulty.

But yes, their service is very impressive. And for a 2 layer board, I can get it delivered here on the west coast USA in usually 6 calendar days from ordering with the quickest shipping. That's shockingly quick, and faster than most local places can even just make the board. (Well faster than any that I know of. I've pretty much switched to only using JLCPCB. Hardly even bother quoting other places these days.)

I believe if you really needed a bunch, they would be a decent price even with the penalties. Every time I've had to pay an extra charge for something, it was a reasonable amount. Though I've never tried to order 100 of anything through them, so I could be wrong.