Thanks i had no idea of the payload implications on the RF.
Using ESP8266 has very different requirements, it’s very power hungry and WiFi can be unreliable for a persistent connection. I have made one that can map up to 10 DS18B20.
the device mapping has to be done somewhere, if it costs too much to send the addresses over the RF they have to be programmed locally. Maybe a LED and a button and some late '80 universal IR remote controller logic could help identify and map each DS18B20? Oh I can feel the pain…
probably 7 emonTh s with between 8 and 16 sensors each - plus between 4 and 12 simpler ones - straight out of the box from the shop here. (the shop kindly will preset the rf id to use more than the default 23-26 range: so can do loads of emonThs )
Will a single ATMEGA pin (5) driving the voltage/power to 14 sensors cope with the current?
That’s beyond my ken.
Not quite true: 2 bytes of the serial number is the family code and that’s unnecessary, so it’s 6 bytes serial number and 2 bytes value. But it still doesn’t help very much. It’s not too hard to have the emonTH as several different nodes, to send the full data set, but at best it would still be 2 Node IDs sending 56 bytes each (the maximum stable payload). Data is sent at around 50 k bits/s, so each would take, with 9 bytes for the header and CRC, about 11 ms to send. So the channel would be blocked for something like 22 ms.
And I’ve just seen that the scale of the installation has multiplied by a factor of 4 - 8. My candid opinion is I don’t think the emonTH and radio is a viable solution any more. An 8-sensor unit will take up two NodeIDs, a 16-sensor one three, and you can have only 30 Node IDs per group, limited by JeeLib. Without knowing the exact allocation, it’s marginal, and that’s not considering the occupancy of the r.f. channel.
multiple, lengthy payloads would hit a battery powered device hard and add significant traffic, possibly blocking other devices.
Power is not an issue as we would not use batteries for these - as
a) they are located in such painful-to-access locations
b) there is mains power already: used to drive the underfloor actuators.
regards blocking on the network - we will want loads of emonTh’s running…
How long ‘on the wire’ is a bog standard emnTH with 2 sensors (int & ext) ?
The issue is more complex than just having enough time for all the nodes since they are not synchronized. The issue is that when the receiver is occupied with receiving one payload it cannot receive another and unless you start introducing acks, any transmissions that start during the time the receiver is occupied is lost, even with a minimal overlap of microsecs, the 2nd packet will be incomplete and fail CRC checks.
Even with short payloads there is a possibility that multiple nodes could transmit at the same time and cause dropped packets, the more nodes the more likely it is to happen. However since the nodes do not all send at exactly n Seconds the devices do not stay synced and every so often one will “overtake” another, whilst “overtaking” one or the other will be blocked. The closer the intervals are to each other in length, the longer the cycle of rotation and the longer it takes for “overtaking” Think 2 lorries on a dual carriageway at almost but not exactly the same speed, it takes forever for the overtaking to complete, Then extend the trailers on those lorries significantly (longer payload) and the effect is it takes much much longer.
As a rule you need to keep both the device count and the payload length short to combat the un-synced transmissions or accept there will be outages (frequent and short if the emonTH’s range in intervals or less often but extended, if the intervals are almost the same).
The reason the transmissions in existing sketches are not synced is because the receiver is put to sleep to conserve battery power so it cannot listen for a trigger, but that isn’t a concern when not using batteries.
As it happens I have a similar project coming up and I had originally planned to just hardcode the sensor id’s into the sketch as the failure rate of these is pretty low (I do not use rj45, I use permanent conns) so the R&D time to make the code handle whatif’s wasn’t justified in my mind. Since then I have been toying with creating an emonhub 1w interfacer so I could use a RPi zero wifi, overkill on the hardware for the task, but the 1wire interfacer would be reusable, even on an emonbase.
I don’t think there is any option that isn’t going to require some modding or code writing, but if if there are enough users wanting something similar, then many hands make light work, however finding a fit all solution is never going to be straightforward.
Hello
@ JustPlaying (deri jones)
maybe you’ve already got an answer…
anyway, here is a link where you can find an arduino library which permits to use many single wire devices such as DS18B20 ou DS2438…
hi Brian
I used it on about 10 different brands of ESPs. depending on the ESP you may or may not need 10k resistor
the ESP i usually use are wemosd1,wemos mini, NodeMcu, esptoy or generic ESP
it would be D4 (gpio 2) on esp for onewire and positive and negative where ever i can grab it…
as to my connection hardware – depending how many DS18b20 i intent to use… I usually build a wemosD1 shield with 5- 10 audio ports and if i need more ports just use a audio splitter or connect several ds18b20 to one audio plug and if i need longer wire just use a audio jack extension cable
Maybe you have a particularly bad environment or some flaky code. I’m sure I’m not alone in having an ESP8266 based system reporting many DS18B20s without a hitch. In my case for a couple of years with 7 sensors and as far as I can tell no problems with the connection. Power cuts haven’t been a problem and the system is on a heat bank, the other side of the house from the router with a 9 inch brick wall between as well as the internal walls. It never fails, the pi which it reports to does lose it’s connection. If I can’t see the pi on the network I can always still see the ESP8266.
I think there was another comment about the number of DS18B20s that an eMonTH can handle, implying it wasn’t a lot. The sensors currently on the ESP system used to be connected to an eMonTX doing PV diversion and performed without a hitch. Actually I say without a hitch but the combo of emonTX RF with emoncms on a Pi actually had lots of issues with dropped connections which is why I moved to the ESP system. The emonTX could certainly manage the number of sensors.
The number of sensors isn’t a problem with the emonTH, its the wireless transmission part of the hardware which could be a problem if there are several emonTH units all trying to “talk” at the same time.
The ESP8266 units are good, but what happens when somebody changes the WIFI password (which ideally you do regularly!) and suddenly nobody can communicate with the temperature sensors anymore
How about this for an idea for the software/hardware:
Using Veroboard or similar, make a pluggable bus - 14 - 3 pin sockets all connected together and then connected to the emonTH
Using the DIP switches on the emonTH, put it into “program mode” (perhaps both off?)
Insert a SINGLE temp sensor into the veroboard
Power on the emonTH - this when scans for the new sensor and stores it in position 1 (eeprom)
Insert the next temp sensor into the veroboard
Reboot the emonTH - this when scans for the new sensor and stores it in position 2 (eeprom)
Rinse + repeat for the remaining sensors.
Put the DIP switches into another position - perhaps to control the base nodeId
If a sensor fails (multiple failures may cause problems) or the sensor is removed, the code could be written to detect this and blank out its programming position(s). When a new sensor is discovered/inserted, it assumes the gap and everything returns to normal.
Using the above, you will then get consistently ordered sensor data which is configured in the order the operator wants (manually via the connections) with the bonus of easy replacement of failed components.
I think we’re all guessing in regard to the actual number of sensors and their disposition. When the requirement went from 1 emonTH with 14 sensors in one location to many with variable numbers of sensors attached, presumably in widely separated places, the problem got a whole lot more complicated. If that can be tied down, then there’s going to be a much better definition of the problem.
are spread about 10-15m apart -all in one building.
2 x 14 sensors
2 x 10 sensors
2 x 6 sensors
Boiler-room sensors
1 x 12 sensors (currently use 3 emonTH’s with 2 sensors each -works fine)
( boiler room is under a concrete floor but no problems with lost samples, so radio connection seems OK -back to emonPi in office room, 20 metres across an L in the building: * Internet connectivity: cabled with ethernet to an ethernet router)
Room temp measurements
a single temp sensor at each emonTh
running 2 right now - will add maybe 5 or 6 more
Short term extras Gas meter
we may be stuck on this: we can;t connect our own ‘spinning magnet’ sensor - because it has an existing ‘meter reading’ attachment from the gas company- we are contacting them to see if we can get online access in their portal to hourly graphs… fingers crossed.
Medium Term extras
Electricity meter pulse counter
Electrical CTs
add 2nd building
we have also have a community hall, 20m away.
Sadly it has electric heating -radiant heaters =- greedy
Would add temp sensor inside: and maybe CT’s on the heating
Would anyone be able to quote me the cost and lead-time: to develop the firmware for consensus solution here - an ESP8266 based controller for 14 DS18B20 sensors.
