I did a couple of quick test with my multimeter and when I had 5v going directly from a usb charger into the sensor it seemed to be behaving as expected. I connected it to my arduino and checked the meter and it was pulsating. I just happened to check the v-in and it was only 3.3v. I checked it right on the arduino 5v pin and it was only 3.3v. I’m wondering if I was sold a 3.3v pro minis instead of 5v and that’s why I have been having so many strange issues throughout this project. There is no reason the 5v pin would read 3.3v is there? Maybe some setting on the pro mini??
Well, I tested 4 pro mini arduinos and they are all 3.3v. Looks like I was sold the wrong product. I’m guessing it’s not likely I will get a refund since I bought them from AliExpress. I did send a message so we’ll see.
@petewill
The 3.3v version is good if you want to create battery operated devices. You don’t need any regulators for the radio either.
If you want to attach 5V sensors you might need a step-up regulator. Like this:
Thanks HEK. I’ll take a look at that. I also think I’m going to be powering most of mine through a wired connection (instead of battery) so I can probably just pull the 5v from there.
I just have to say, this is by far the most fun project I have worked on in years. Thank you so much for creating this. I just started with Vera and I am already loving it. Very addicting. Thanks again HEK!!
Is it possible, or feasible for future improvement, to be able to set in the sensor sketch the Vera “Room” you want the device created in and the Name of the device?
I was thinking these could be parameters of the gw.sendSensorPresentation entries.
@gregl
I would rather not mix vera specific configuration into the the MySensors Arduino library. We’re currently developing a Raspberry controller for the library where the room concept just don’t fit (in a Vera way).
Also, on the Vera side, the room assignment is a one-time configuration.
The radios are defaulted to a data rate of 1 mb/s. The newer radios (+ suffix) also allow 250 kb/s. The lower speed should increase the range of the radios (I have no figures on by how much) but it seems a high speed is not necessary for most sensors. Could the next release allow for the data rate to be altered or the default changed?
I would image that the speed parameter eg RF24_250KBPS would passed into Gateway::begin() together with the existing radio id and passed down to setupRadio() in sensor.cpp
If the parameter was not passed, then the radio could stay at the default? Likewise I believe there are some bits, in some register somewhere, that indicate if the IC is the newer type - if it not the new type, the RF24_250KBPS request would be ignored, as the old type doesn’t support it.
The radios are defaulted to a data rate of 1 mb/s. The newer radios (+ suffix) also allow 250 kb/s. The lower speed should increase the range of the radios (I have no figures on by how much) but it seems a high speed is not necessary for most sensors. Could the next release allow for the data rate to be altered or the default changed?
I would image that the speed parameter eg RF24_250KBPS would passed into Gateway::begin() together with the existing radio id and passed down to setupRadio() in sensor.cpp
If the parameter was not passed, then the radio could stay at the default? Likewise I believe there are some bits, in some register somewhere, that indicate if the IC is the newer type - if it not the new type, the RF24_250KBPS request would be ignored, as the old type doesn’t support it.[/quote]
You can already change the speed in your sketch/gw by doing:
gw.setDataRate(RF24_250KBPS);
or
gw.setChannel(42); // If you want to switch to another channel
Sensor/Relay/Gateway are all subclasses of the RF24-library.
If I flash/upload a Nano board with your recipe - e.g HumiditySensor… should the Gateway see it regardless if the sensor itself(The actual DHT22) works?
I ask because I have three Nano boards. Two work fine but a third will not get seen by the gateway. I have tried it with the Humidity sensor setup and the Motion detection setup. Obviously flashing the right files in between.
On this one Nano, I have the green power light but to the left I have an intermittent red LED labeled L with keeps flashing… is that something wrong with the board or the files or the sensor? To be clear, there are two other leds for RX/TX and they active only when I I reflash the nano.
[quote=“konradwalsh, post:56, topic:179310”]If I flash/upload a Nano board with your recipe - e.g HumiditySensor… should the Gateway see it regardless if the sensor itself(The actual DHT22) works?
I ask because I have three Nano boards. Two work fine but a third will not get seen by the gateway. I have tried it with the Humidity sensor setup and the Motion detection setup. Obviously flashing the right files in between.
On this one Nano, I have the green power light but to the left I have an intermittent red LED labeled L with keeps flashing… is that something wrong with the board or the files or the sensor? To be clear, there are two other leds for RX/TX and they active only when I I reflash the nano.[/quote]
The motion sketch is no problem to run without sensor. Unsure about humidity… i doubt it would crash (at startup) even of sensor is missing.
My first options would be to check wiring of radio.
I fried one of my nodes (node 4) so my nodes are now 1, 2, 3 and 5. The Gateway still thinks there is a node 4, even though I removed it via UI5, so it keeps trying to reach the node. For example, the Gateway messages below with DEBUG enabled.
What is the best way to clean up the node/routing topology to prevent the errors above?
I want to try a different radio module for my gateway because I am suffering reliability problems when sending to/from nodes (I have already tried decoupling capacitors, lower data rates, etc). If I build an entirely new gateway circuit, flash it and physically swap it for the existing Serial gateway, will the Vera see it as the same gateway (i.e. same radio id, etc.) or do I need to do something special to avoid it being seen as a new gateway? I also wonder if the core reliability issue is the ghost node 4 above because it could traverse a non-existent route.
I fried one of my nodes (node 4) so my nodes are now 1, 2, 3 and 5. The Gateway still thinks there is a node 4, even though I removed it via UI5, so it keeps trying to reach the node. For example, the Gateway messages below with DEBUG enabled.
What is the best way to clean up the node/routing topology to prevent the errors above?[/quote]
Repeatings/Relaying nodes have a “clear”-button to clear routing table in EEPROM (advanced settings). Unfortunately the gateway misses this (as I forgot to implement it for the GW).
But the routing table will correct itself once a message comes in from a new “node 4”. The question is why are you trying to send messages to a none existing node?
You can always use the clear-eeprom-sketch if you really want to clear everything.
Just replace gateway. The routing table will be build up again once the gateway receives messages from sensors.
The ghost issue you see right now will disappear. But is you try to send messages to non-exisiting-node 4 you will see other error-messages (missing route etc.).
Thanks for the quick response. I am not explicitly trying to send messages to ghost node 4… For some reason, the gateway is trying to send messages to ghost node 4 for reasons that I do not understand.
I have wired up a new gateway and am going to swap it out to see of the other radio module is more reliable and it sounds like doing so will automagically clear the routing table… I will post the results here.
That said, if I add a node in the future, will the gateway assign it to node 4 or node 6 (i.e. will it fill the first gap it finds)?
Finally, I know the Ethernet gateway has nearly maxed out the flash but have you considered adding a frequency scanner to the gateway as an advanced option so users can optimize the gateway channel?