@MikeF Dirtypcbs rarely takes more than 3-4 weeks for me too (in germany), but you are right, a local source would be great. There are several producers here too, but for everyone I know prices are at least 5 times what the chinese take.
If you (or someone else) finds a european service that produces prototypes (1-3 boards) for less than 15€ per piece please share it! Could come in very handy when developing new boards.
If you mean the MG811 on that list: it's pretty bad.
Long warmup times (24 hours..)
Doesn't really measure CO2, but responds to all kinds of other gasses too.
Loses callibration. It's mostly a chemical proces.
The cool thing about the MH-Z14 and the even better MH-Z19 is that they use light spectrum analysis. They send infrared light, and measure how much of that light is absorbed in the spectrum that CO2 absorbs in.
While not very accurate, they are very precise.
So they are not very good in giving absolute values, but they are very good in measuring relative changes.
These sensors have a function where you can set the baseline by sending them a specific command. For example, you could take the sensor outside, and then set the outside value as the zero mark. Or you could just use the value they put in at the factory.
there is no "right" or "wrong" answer to this questions imo. Both concepts have their two sides.
Personally, I prefer to go the multisensor way (and also use RS485, which limits the numbers of sensors to 32 per gateway with standard interface boards). In addition to that I also like the idea to let the arduinos decide (some) things locally or make them configurable to some extend. So things may not become completely out of controll in case there is (temporary) no controller.
Less parts, especially power adopters/batteries,
less "optic irritation"
better use of arduino potential (use of more than 40% of the memory, not sleeping all the time)
Less RF, means also lower risk of RF conflicts (or best: no RF at all => RS485)
in case of e.g. failure or power off, I will most likely notice this earlier because of the bigger "footprint"
its (sometimes) hard work to get things working (but also fun and satisfaction )
higher risk of messing things up because of bad code (I am just a beginner in programming. This is more related to distributed logic as mentioned above; just combining some simple examples isn't rocket science...)
in case of e.g. failure or power off, a multisensor has the bigger "footprint"
So it's up to you which way to go (or to which extent, to be more precise).
AM312 based complete PIR sensors, basic sensor with Vcc, GND and output. Claimed consumption on datasheet 20µA.
AM612 PIR sensors (sensors only). This include all the circuitry in the metal cap, so you only have to add basic components like caps and resistors to set parameters: sensibility, trigger duration. Claimed consumption on datasheet: 15uA.
I'll try to test them this week to first see if the claims are true (or at least, not too optimistic ) on power consumption, then I'll make some basic sensors to check range and stability for a while.
Well, I'm glad that the posting got some traction and some very interesting ideas were shared. While the bits and pieces of information were all out there, your argument helped drawing some conclusions.
LoRa is NOT an option for HA. alexsh1 explained one scenario and I'm actually using LoRa (not LoRaWAN) in my building, but both cases make use of LoRa only because it's a new cool technology. @alexsh1 your friend could properly cover his home with 2G/3G signal either for free, by asking the provider to improve the coverage in that area, or by buying a GSM repeater. And I could ask a neighbor to share his WiFi connection so an ESP8266 module could do the job.
The protocol addresses very specific segments where a great urban coverage is required and for that to happen no node should exceed a radio power of over 100mW.
There is another case where everything was traded off for the sake of range, the ham radio JT65 protocol. I was able to successfully transmit a signal from Romania to Brazil using 5W RF power and a 1m diameter magnetic loop antenna. It's great for long distance, narrow bandwidth (200Hz wide channel), low power but it sends data at a "whooping" speed of 13 characters per 50 sec, during which it draws about 1.8A from a 12V battery (21.6Wh).
My original idea of LoRa <-> RFM69/RF24 is not feasible unless, some serious downsampling is involved, as buffering the raw data before sending it out is really useless because LoRa doesn't have a serious overhead that would be addressed by concatenating larger chunks of data in a single packets.
So at the end of the day, it really leaves us with a couple of applicable scenarios when taking public LoRaWAN meshes into consideration. Smart meters and perhaps security devices which only have to send a daily keepalive ping and if ever needed, tripped sensor alerts, provided that they would be immune to jammers. I'm not taking into consideration the close range stations where a daily 30s air time would suffice, because this defeats the purpose of LongRange. Other than that I see no real use of LoRaWAN, but feel free to share your ideas, perhaps I'm missing something.
And after apparently trashing both LoRa and LoRaWAN I will only say that I can barely wait to get myself a LoRaWAN gateway and set it up in my area
@Grubstake mine looks like those in the picture you have just posted. Well, if you got 2 out of 4 working, I should not be that surprised I've had so many issues so far
I will also try ordering those @gohan suggested, just to evaluate all the options and report back
@tomasandersson Just 2 DS18B20 on each line should never cause trouble wrt current draw using a 4.8k resistor and 30 sec. intervals and no additional sensors drawing current from the arduino. If not already in place I would anyhow recommend using 3 wires for operation instead of parasitic mode.
Anyhow: Best way to identify these chips is using the addresses. Most likely you now are also prepared to do some small editing in sketches?
"My" array-sketch-version also prints the ID's as array information you need to serial. You may test it and then disable this feature once you have the info for both of your sketches (begin the respecting line with the #define with a "//"). Doing so will definitely eliminate any smallest risk of mixing data...
@napo7 thanks for response. Actually I want to avoid such solution. The main reason is the reliability. Just want to have wired connection between switch and the actuator. I tried the solution with resistor ladder like this:
So pressing different switches (SW1 to SW3) should result in different resistance seen between ADC PIN and GND. And to be able to detect multiple switches pressed at the same moment the resistor values must differ. Unfortunetly this makes very little differences between some combinations, and i'm afraid that on 5 meter long wire the noise will cause misdetections. Does anybody used such solution ?