Hi Dave, I currently use a separate serial interfacer in emonhub, for each emonTx. They will usually get automatically addressed as /dev/ttyUSB0, /dev/ttyUSB1, and /dev/ttyUSB2 but have no control over which is which (not so good!!!) but as long as the node id is written into the sketches payload this isn’t a problem until you have other USB devices and the addressing range gets altered.
I use FTDI serial adapters with a writable eeprom and have added udev rules so emonTx’s are automatically recognized and use their own serial numbers as addresses e.g.
pi@emonBase5(ro):~$ ls -la /dev/emon*
lrwxrwxrwx 1 root root 7 Oct 11 16:21 /dev/emonTX-TX4O3K2 -> ttyUSB1
lrwxrwxrwx 1 root root 7 Oct 11 16:21 /dev/emonTX-TXPTU5K -> ttyUSB2
lrwxrwxrwx 1 root root 7 Oct 11 16:21 /dev/emonTX-TXTNIZG -> ttyUSB0
because I am using USB=>serial for comms so there is a 5vdc connection to be had, powering the emontx via the 9vac can have a slight impact on the voltage waveform, not necessarily enough to justify putting in a separate 5vdc in most instances, but since it’s there it is the better option.
The real benefit is the 100% success rate for getting all data, 3 emonTx’s on the same RF network will result in lost packets, due to having almost exactly the same time intervals, when 2 emonTx’s clash timewise it can take half an hour for the clashing to pass depending on the send interval, length of payload and the accuracy of the interval timing.
3 serialUSB adapters and leads is not really any cheaper than an rfm2pi receiver, but the data is much more reliable.
Hi pb66, could you possibility go into detail into this? the wiring part at least Serial as in using the UART connections using something like usb to serial? I was trying to see how you got this plugged in from the TXs to the base but couldn’t quite tell from the pics, i see some cables coming out of each Tx but cant tell where/how they get to the base
The USBs coming from the base, are just powering the TXs right or you have some split somewhere leading to the serial adaptors?
EDIT
ohh wait, i think i get, you’ve go those connected to those adaptors hidden under the boards (I noticed USB is not the one in the Tx) and that also takes the 5V input as you mentioned.
The shop sold serial adapter/programmer is based on a SiLabs CP2101 chip, the ones I use are based on the FTDI ft232rl chip which has an eeprom, this is important if you wish to simplify the connection and identification, it is not impossible with other serial=>USB devices but the eeprom and id number make it much easier.
“FTDI” is a brand, although “FTDI” has become an unofficial generic term for a USB=>serial adapter.
Here is a pic of the emonTx stack flipped over, I remove the battery holders and use a double-sided stickey pad to attach the FTDI.
Because you can only connect one device to the one serial uart on the gpio, not 3. And sometimes I also install several emonTH’s and/or remotely located emonTx’s, so I can still add an RFM69Pi if I choose, and the 3xsingle phase boards are all connected the same way.
That sounds like a lot, how have you saved that much?
The 3x FTDI and 3x USB leads may well cost significantly more than the one RFM69Pi, unless you take a chance on cheaper Chinese ebayers, which could save you money or cost you 3weeks when you have to get a refund as they are fakes, believe me I know!
i would recommend using ebay over Amazon as their buyer protection means if you order something that says “Chip: FT232RL” and it turns out not to have an eeprom, ebay will guarantee a refund, Amazon is not so quite so accommodating, it is down to the seller.
Verified Purchase
Does not work - the chip is a counterfeit, and so it gets “bricked” by the FTDI driver (see this article for details: […] After connecting it to my machine the USB PID of the chip gets set to zero, i.e. the thing has been killed
Indeed it sounds bizarre when you say it like that, but the reality is you are probably more likely to get a fake on Ebay than Amazon (maybe?) but the buyer protection of Ebay puts the risk on the seller rather than the buyer.
unfortunately there are so many large scale fraudsters manufacturing upstream, that many of the sellers on Ebay AND Amazon are not sure of what they are selling. I have bought from several sellers and tried to get repeat orders in place as soon as I receive and test the first ones, only to get fakes in the second batch, there really isn’t any telling in advance, so you have to pick a supplier on Ebay that says they are “FTDI ft232rl chips” and accept that they may arrive and be useless and need refunding, on Ebay you are only gambling on how long it might take to get ones that work correctly.
This is why I haven’t recommended a supplier, I cannot say if my last good supplier has got fakes or not. Likewise that poor guy on Amazon that had the poor review, he may have good stock now.
Do not worry so much about the “driver bricking the device” some time ago FTDI got upset about the counterfeits and updated their windows driver to “brick” fake devices by changing the PID and VID, the drivers have long since been revised again so this no longer happens.
Consider a 2 box strategy as the heat from 4 ac adapters in a confined box will cause the Pi to tick over at well over 50 degC depending on ambient temp, where as a separately boxed Pi can run up to 10 degs cooler.
I’m just going to do the ‘metering box’ one, I’ll leave all the sockets and such to the electrician and simply lead the adaptor leads inside after
BTW what spacers or total height of the stacked Tx block you have? I think 20mm spacers are more then enough thus 90mm depth box should do the trick, just wanna be sure
If you are buying a bag of 50 or 2 bags of 10 etc. you can easily cut down a set of 4 20mm spacers with a knife, to give you a set of 4 deep nuts and 4 thumb wheels instead of buying separate screws and nuts etc.
Still waiting on the resistors and FTDI adaptors, then ill remove the bat box and existing resistors.
I have the rPi all up and running with emonHUB and emonCMS, just need to the the udev rules and such once they arrive
@pb66 you seem to be quite skilled in the emonCMS/emonHUB (from what ive seen around the forum) so I thought I’d ask, do they need MQTT? I set it up with emonHUB outputting straight to the emonCMS , but I found some references that seem to indicate it needs/uses MQTT to send this data… so not sure
The emonSD uses MQTT to post to the local instance of emoncms, so if you are running an emonSD yes MQTT is required unless you make some changes. However neither emonHub or emonCMS are dependent on MQTT.
For my own applications, I do not use the emonSD or run a local emonCMS at each site. Nor do I use the “emonpi” variant of emonHub, I have all my sites run original emonhub on a totally read-only OS image, all reporting to a single emoncms server over https.