@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 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.
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!!!
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.
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!!!
Thank you - I hadn't seen that page yet. I've tried to very carefully follow this page, though: https://www.home-assistant.io/integrations/mysensors
When I use the 2.x example on the page you linked, I do get the sensor to show up in the Configuration/Entities page. However, when I do, it has the edit symbol crossed out and when I click on it, it says: "This entity does not have a unique ID, therefore its settings cannot be managed from the UI."
I've tried to look wherever I could, but I can't find a way to get MySensors to report an ID. Is it possible? If not, do I then edit the .json file, or where can I go to fix that?
Thank you so much! I feel like I'm super close to getting this!
Well, I've made a bunch of progress, and found a few small errors. I simplified everything down to just using the 'Dimmable Light' from the Example folder in MySensors-provided source code. I did change a bit to match my radios and settings, as well as providing a value to the gateway the first time it runs so that it would show up in Home Assistant.
Now I have checked the mysensors.json file on the server, and it has gotten the data from the sketch! So I know that the radios, gateway, and MQTT server are all doing their jobs.
However, I can't find any new devices or entities in Home Assistant that match the light. Since this is my first time adding something through MySensors, I'm not sure what it's supposed to look like. Do they show up automatically, or do I need to go tweak something? One thing I read talked about having an entry in the configuration.yaml file for each device, but another said it shouldn't be needed anymore.
I'm going to mess with it some more next time I get a chance, but it's late here now so I need to be done for the day.
If it helps, here's what my mysensors.json file looks like for that sample sketch:
"1": {
"sensor_id": 1,
"children": {
"1": {
"id": 1,
"type": 31,
"description": "",
"values": {
"3": "0"
}
},
"2": {
"id": 2,
"type": 31,
"description": "",
"values": {}
},
"3": {
"id": 3,
"type": 31,
"description": "",
"values": {}
},
"4": {
"id": 4,
"type": 31,
"description": "",
"values": {}
}
},
"type": 17,
"sketch_name": "Dimmable Light",
"sketch_version": "1.0",
"battery_level": 0,
"protocol_version": "2.3.2",
"heartbeat": 0
}
Thanks!