@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.
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...)
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.)
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.)
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.
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!
@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!
@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.
But back on topic - that device looks pretty cool, if it does half of what it claims. I'm a little tempted, even at my own cost. I won't, but if my insurance company ever offers it, I'll jump at it.
Yes, it's a little 1984. But I also already signed up for an app with my car insurance that monitors my driving. It doesn't have any hardware, just GPS and accelerometer from my phone, but it doesn't cost me anything other than some power and I guess privacy. But it saves me something like 15% and I don't have to do anything. I guess if I ever really care about it watching me go somewhere I can disable it for that amount of time.
A little weird what we're willing to put up with, I guess. Though I also like the fact that with a record of how I drive, if there's ever an accident, it might also be possible to subpoena the data in my defense if really necessary. Or maybe that's just what I tell myself to help justify it? 
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.
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.
Well, I don't know what all is in the video, because I'm not going to watch a 27 minute video about it.
However, those modules often fail due to bad power supply. Adding some capacitance to the power rail is supposed to take care of it. I've read about it multiple times, but I haven't used them hardly at all myself.
Oops, I missed the latching part somehow, even though it was stated multiple times. That would take a few more transistors. Though the way I would do it would be to just use an H-bridge motor controller chip/board. They would have everything you would need, as well as most having the free-wheeling diodes built in.
I haven't checked it all out, but I do like that you have a diode on the relay coil to keep the voltage from spiking.
What voltage is VDD? Maybe it says somewhere, but if so I missed it.
But in general, it's better to have a combo of mosfets so that the relatively low voltage out of the Arduino can control the higher voltages safely.
The problem is that an N channel mosfet needs a positive voltage between the gate and the source. You've only got 3.3V available for the gate signal in your diagram, which means that best case you're going to have a threshold voltage difference. So the source voltage is down to say 2.8V. That's not going to do much for your solenoids.
You can rearrange the system and get rid of the relay so that you are only switching the low side of the solenoid and you have diodes for the high sides. (I haven't drawn it out, but I think it should be possible.)
Alternatively, you can have N channel mosfets or NPN bipolar transistors controlling the gate of a P channel mosfet that does the actual high-side switching. Figure 3 of this doc shows the basic circuit for mosfets. If using an NPN in place of the N channel mosfet, it only requires small changes to the circuit. https://www.vishay.com/docs/70611/70611.pdf
I'm not skywatch, but I also agree that I prefer Open/Closed, because sometimes a house will have vertical blinds, so it makes more sense than up/down. How hard is it to have both? I haven't dug into the code.
Yeah, the pin change interrupt really gets you the benefit of the diode plan that was talked about, but without using the extra pin. You still have to check which pin has changed, if you have multiple pins enabled for the interrupt, but that's still the same level of work as checking all the pins under the diode plan.
Saves all that extra hardware/soldering as well. You just need to hook up to the input as you normally would. Though with the board you're using, maybe things are already connected, and you just need to enable things and then check the input?
It sounds like you're making this more complicated than it has to be. What you're asking for is already supported and is pretty easy to do. It's just part of the microcontroller and is straightforwardly part of Arduino, and therefore mysensors.
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.)
@mfalkvidd In addition, since the later sensors are seeing it, it's probably just that the power supply is drooping before the voltage regulation on it can catch up. They kind of have 'inertia' and can take a bit to respond, and of course every power supply is different, based on how it's built.
So likely the capacitors are helping it ride through the first transmission, and then the power supply 'catches up' for the later ones, but the second one gets garbled with the lower power, and the receiving radio chucks it as a bad packet.