I have an EmonPi2 (I believe technically running the EmonHP firmware, for some reason) with an attached Anker USB hub. Attached to the hub are 6 12-port EmonTX5s. Exactly two of EmonTX5s lose connectivity to the main unit– one of which is visible via the serial config / serial monitor (but which does not update its inputs/data feeds) and one which does not show up in the USB device list at all. It’s always the same two units; switching USB cables or ports on the USB hub does not change the behavior. I have noticed that one of the Tx5’s USB connection appears physically loose/dodgy as the corresponding indicator light on the USB hub blinks on/off according to how the cable connector is jiggled.
The system is in the US (110V split-phase) and I have a VSMon unit and 5 or 6 of the “splitter” connectors daisy-chained to the Pi2 and all along the Tx5s, in case this could be power-related.
I’m looking for assistance with the following:
Diagnosing the dodgy USB connection and/or submitting an RMA if needed.
Configuring all the Tx5s with a unique ID so their data are correctly associated with inputs regardless of what USB ID, port, etc the device is connected to. (I have already added the ‘by-id’ com_port settings to the emonCMS config.)
Submitting a feature request that this unique ID be displayed in the serial messages sent from the TX5s for identification purposes when chasing down ‘mislabeled’ or mis-plumbed data feeds.
[if needed] cleaning up the old inputs/feeds/… for the two misbehaving Tx5s and recreating them. I am willing to factory-reset everything and start fresh, but I’d rather not ‘nuke it from orbit’ if there’s a more graceful/surgical approach.
[tangent] While I’m in there I’d like to configure the default voltage to 110 (118, usually) to reduce the amount of “negative wattages” being reported.
Why do you think this? I don’t know the detail differences between the two - did you buy it as a “Heatpump Monitor” (and do you have a heat pump?). If you tell me why, I can ask or @TrystanLea can probably clear this up.
Is this one of the “two of EmonTX5s” or another one?
In any case, that shouldn’t be so. Email The Shop [email protected] and include a link to this Topic.
Surely you mean 120 V? 110 V is commonly used in industrial automation here in the UK, or as 55-0-55 V supply for portable tools.
Typo? You mean emonVS.
Probably not, as each emonTx is getting its 5 V supply from both the emonVs and (presumably) your USB Hub, but I wouldn’t rule it out. You could try moving the “two of EmonTX5s” nearer to the emonVs in the chain.
These are essentially the same thing, are they not? When sending the data serially by USB, it is sent in “name:value” format so the software needs changing to add a “unit” prefix, so that it sends something like "TX1_V1:118.4, “TX1_V2:117.9” and so on. @TrystanLea is the person who must implement this, if you feel able to install the Arduino IDE and the necessary libraries, I can steer you in making the necessary changes and uploading a new version to each of your emonTx5s.
You may delete inputs as necessary. As soon as new data comes in, the input will be created. You then need to add back all the input process steps, and continue writing the data to existing feeds (if they’re valid), otherwise in the delete menu on the Feeds page either Clear the data completely or Trim it (delete the data up to a time).
There isn’t a default voltage. The software in your emonTx5 was never intended to work (and won’t work) without a voltage sample so that it can accurately calculate real power. You do have a 3-phase emonVs and you have connected L1 to one leg of your split supply (Black), L2 to the other leg (Red) and N to your Neutral (White)? The emonTx5 won’t work properly otherwise.
So I completely don’t understand what you mean by this. You’ll get a negative value for power (and a negative-going value for energy) if what is normally a consumer of power becomes a generator of power – commonly if you have PV or wind generation on site. And in this case, a negative power is genuine and correct. Our convention is, for the whole house, imported power/energy is positive, exported is negative. So when the sun is shining, your PV inverter output is positive. Overnight, it’s a few watts negative. If you are generating more than the house consumes in total, then the nett power measured on your two incomers will be negative, and that’s correct too.
I’m new to this forum software so please excuse / ask for clarification on any points I’ve bungled up, especially formatting-wise. Also, thank you for your thorough response!
Why is it like that? No idea, that’s how it came out of the box. Had to write in to the support line to get the correct default password as the one on the website didn’t work.
Sorry, yes, it is. I will contact the email as suggested.
Yes, it’s 120V; I’m not sure why but around here it’s interchangeably referred to as 110 (and 220 for both legs). Actual AC voltages hover around 118V from L1/L2 to ground.
Indeed I do, yes.
One of the two malfunctioning units is at the end of the chain; the other is 2nd from the emonVS. I’ll still try the experiment though.
I was thinking something more along the line of “TX_0xABCD:M:#” as the message prefix, to minimize the parsing changes - or to add an id:0xABCD element on (/to the end of?) the message. With randomly-assigned unit IDs, the odds of getting a collision in even a large (8 node) system would be minuscule.
OK, so what I think I heard is:
Delete the defunct/non-reporting devices
Delete any inputs that appear to be associated with those devices
Shut down the system from the web UI
Remove power from the system
Unplug all but one of the ‘missing’ units’ USB cables
power up the system, see if it registers and starts reporting in; make sure its name has part of the unique USB ID
Plumb up (TBD) its inputs / feeds
Repeat for the other unit
(disable autoconf?)
Shutdown/power-off everything again, bring the whole system back up, hope everything re/registers.
I had an electrician do the wiring as it’s inside the mains panel, but from my recollection yes. L1 and L2 show correct voltages and IIRC there’s a slight voltage drop between the first Tx5 and the last working one in the chain. If the emonVs is measuring ‘against’ L3 then I can only assume it’s the neutral.
There is no generation on-site. Some circuits return positive wattages, others return negative wattages; all should return positive as all are consumption-only branch circuits. These are not small number noise measurement issues (-4W, sort of thing) – one circuit consistently reports -300W, for example.
It was perhaps a dozen or 18 CTs out of 76– enough that I had the electrician back into the panel to check those CTs were on correctly; they appear to be. The best hypotheses I have are manufacturing error – batch of CTs soldered ‘backwards’, perhaps?— or some connection problem. I checked the 1/8” miniplug connectors going into the Tx5s, and they seem to be seated securely. Open to other things to try though! It does seem mysterious.
Sounds good; I expect to pull the solar values off its modbus network when it comes online, so I won’t need more OEM equipment for that. If I can’t figure out the physical measurement problem, I’m considering just writing some python to call the OEM REST APIs and put an absolute-value calculation as the first step in every input’s processing.
Each emonTx makes its own measurement of the voltages (they aren’t shared), so unless you have a long high resistance piece of Ethernet cable, the voltage drop should be minimal: you have 6 loads of 27 kΩ ( = 4.5 kΩ) loading a 75 Ω voltage source, so unless the cable resistance is of that order, you shouldn’t see a significant drop.
If Trystan’s Serial Config Tool will accept a negative calibration constant for the c.t. (I’ve never got it to work on either of my emonPi’s, so I can’t test) then that will reverse the sign of the power and energy. If it doesn’t, you can still type the command and send it using Serial Monitor. The software in the emonTx will accept a negative calibration value. Or put a -1 multiplier as the first step in the Input process list.
Otherwise, I think (mainly because I don’t know Python and because I wrote the library that does all the work) the easiest way will be to set up the Arduino IDE and edit the sketch in each emonTx.
Sorry to hear you’re having problems John. A few things to add to Rob’s suggestions:
For the unit with the “wobbly” USB port, I’d definitely get in contact with the shop to get that replaced.
Do the faulty units work in isolation without the USB hub in between?
On the Pi2/Tx5 there is no protection between the emonVS power supply and the USB supply (fixed in Pi3/Tx6), I wonder if that’s causing an issues especially if you have your Txs chained in series - I’m not entirely sure how that would manifest itself.
Including the unit ID in the serial message would be straightforward, but would break consumers not expecting the extra field, unless it’s included as part of the field name (easy, but a bit clunky as it’s repeated redundantly). Using the RF link, each unit’s ID is sent but that is not in the current serial message.
You can be a bit more rigourous in assigning random IDs (if you prefer random to assigned in the serial link). A lot of microcontrollers have a unique ID burnt in to them. For the Tx5, the AVR DB has a 16 byte unique ID, starting at 0x1110 in the system address map.
The argument would be between the Hub (and/or what’s powering it) and the emonVs’s 5 V PSU. I think it would affect all emonTx’s more-or-less equally.
This is exactly why @TrystanLea needs to be involved. If the ID was optionally sent before the message count, it could be dealt with in emonCMS or ignored as required (in the Interfacer presumably) at minimal overhead in the message. Coming from the source is more satisfactory than relying on the USB port allocations, no accidental cable swaps etc. I suggested adding it as a prefix to the value name only because it can be done immediately and simply, and it breaks nothing. (It’s exactly equivalent to naming Feeds “PV power” etc.)
