Hello,
I want to monitor the temperature in a block of flats appartments. The goal is to have between 20 and 40 temperature and humidity sensors.
Is OEM suitable for this purpose? In particular the fact of not being able to exchange with the server since it will certainly be necessary that I move a laptop with an antenna.
I am interested in your feedback.
Thank you
If you use our standard software, which uses JeeLib, you may have up to 28 emonTH temperature and humidity sensors in one group reporting to one emonBase or emonPi. To have more, you would need custom software in the additional sensors to put them in another group, and custom software in the receiver to handle the second group. These are limits imposed by JeeLib. Note that all of the sensors use the same radio frequency, therefore you could have a problem when more than one is transmitting at the same time.
You might wish to look at the LowPowerLab library - I have no knowledge of that library, but it might not have the same restriction on the number of sensors. I believe using it would require only a small change in our software.
With that many nodes, it’s more like he will have a problem with packet collisions.
Given the long interval between transmitted packets, the actual amount of data lost might not be too bad.
Over what sort of floor area / distance? Sensors x Flats per floor x floors? Could you put one ‘base station’ per floor communicating via WiFi?
How accurate? What is the structure Brick / stone or partition walls? New / old build or conversion?
I suspect any system will not work like this.
The standard sketch transmits 12 bytes of data, plus 9 bytes of overhead, at the rate of 49.23 kb/s, at intervals of 55 s approximately. Doing the maths, that means one transmitter occupies the radio channel for ~3.4 ms every 55 s, or 0.0062% of the time. 40 transmitters will together occupy the channel for ~0.25% of the time.
The standard sketch caters for an external temperature sensor plus a pulse count. Editing the sketch to remove those, assuming they are not wanted, will reduce the data to 6 bytes, it will transmit for 0.975 ms, or 0.0017% of the time. All 40 will occupy the channel for 0.07% of the time.
Provided that transmissions are evenly spaced, there is little chance of packet collisions. But as we know, there will be small speed differences and it is inevitable that collisions will occur.
I thank you for all these exchanges. The sensors will be spread over 14 floors of a building built in the 1970s. These are concrete walls and floors.
To avoid the transmission problem it seems better to move towards Lora sensors. I do not know at all so I have an appointment with a company in two weeks. What annoys me the most is not having a solution to collect the data myself.
I will keep you informed of news
Hi
Lora sensors are a good option…
If there is an http REST API with your sensors, you should be able to use nodeRED to inject your measurements in EmonCMS
I have done a similar project with 20 sensors, not Lora but 169 Mhz ones working in wireless modbus…
check Enless Wireless - IoT and M2M radio sensors for energy monitoring
I am using emonhub with the modbusTCPinterfacer and it is working fine with my 20 sensors for more than 6 months…I have more than 100 meters between the sensors and the emonPI used as the base, connected in ethernet to an Advantech smartflex 4G router with RS485 support built in, linked via RS485 to a Enless modbus receiver – RS485 interface…
if the 169Mhz signal is low (less than -90dBm - a usual value is between -70 and -90 dBm, an excellent value is above -70 dBm ) you have to install a repeater
You can face transmissions problems when you instrument buildings with metal structures, having many metal doors, but repeaters solve them
If you want such a system, I can provide help
Alex
Surely you mean less than -90 dBm, as more than -90 dBm, e.g. -80 dBm,
would be a stronger signal vice a weaker one.
Sorry for the language abuse.
Thanks for the correction…I 've edited the post…should be clearer now…tell me if not
Looks good. 