Hi - I have a new Eagle 3 (which replaces my dead legacy one after 8 years).
It seems to push to PVO just fine but as soon as I start exporting PVO is return http error 400.
I’ve raised it with rainforest support, but is there anything else I can check to see the specific error description?
A 400 means there is data issue - check that the “tz” (timezone) has been configured correctly to the system’s location.
e.g. eaglepost.jsp?sid=***&key=***&tz=your_timezone
List of timezones -
OK, but I don’t think it’s the time zone in this instance.
The eagle is able to push fine from dusk till dawn then it starts getting the 401s.
I have a SolarEdge inverter that is already reporting generation (not usage, no CT’s installed).
Then I have the Eagle which is reporting NET from the meter.
This setup has worked for years, but the eagle died, so I got a newer one.
In the past PVO was (correctly) able to determine my power used from Power Generated + NET (from eagle).
It appears that PVO is throwing the error whenever NET (from my meter) is negative…maybe because it disagrees with the value from SolarEdge which has zero for power used?
May not be relevant, but I notice a new set of documentation for Eagle 3 uploading avaialble on Rainforest Automation site. Configuring Uploaders for the EAGLE 3 : Support Center
Yeah thanks. I noticed that, but noting there to help.
It does have pvoutput defined as a built in template now, that’s what I’ve been using. Maybe there’s something being pushed that I’m not aware of. No way of telling.
The problem is that when it gets the 400 error, the eagle doesn’t display the accompanying description coming back from PVO which might give me a hint. I’ll raise that with them as a suggestion for future releases.
When I look here I can get an idea of what sort of errors are possible:
https://pvoutput.org/help/api_specification.html#id4
I might try using my own config for PVO rather than the built in one and tweak what’s being pushed.
If that still fails, I’ll have to get it to push to something, capture that, then manually push that to PVO and see what the error message is. This is exhausting,
Having captured a few of these requests for the system, it is sending excessive consumption data.
The error 400 is “Power value [16774396] too high”. i.e. 16MW
Raw push data you can send to rainforest support to examine -
<rainforest timestamp="1677044575s" version="2.0" macId="***"> <InstantaneousDemand> <DeviceMacId>***</DeviceMacId> <MeterMacId>***</MeterMacId> <TimeStamp>0x2b8867dd</TimeStamp> <Demand>0xfff4fc</Demand> <Multiplier>0x00000001</Multiplier> <Divisor>0x000003e8</Divisor> <UnitOfMeasure>0x00</UnitOfMeasure> <DigitsRight>0x03</DigitsRight> <DigitsLeft>0x07</DigitsLeft> <SuppressLeadingZero>Y</SuppressLeadingZero> </InstantaneousDemand> </rainforest>
Demand hex value 0xfff4fc converted to decimal is 16774396
Ah, ok, perfect thanks.
I reckon that’s actually supposed to be -2820 which would be ff ff f4 fc
Not sure why they would just send 3 bytes…
I’ll see what they say.
Is it possible you are not parsing this properly? When I look at their spec they are usually sending the demand value as a 3 byte signed int, eg:
0x001738
How would you expect a negative value to look?
0xfff4fc = -2280 (W)
I’ve looked closer at this.
The spec for the “Raven instantaneous demand” xml specifies that the value for demand is in the range 0x0 – 0xFFFFFF so the value my Eagle is sending to PVO is correct.
The problem is on the PVO side?
The uploader spec states that the instantaneous demand is a 32-bit number (4 bytes). But from @bankstownbloke push data above, Rainforest is only sending 3 bytes. I would say that Rainforest is violating their own API.
Sign extension matters so 0x00fff4fc = 16774396 while 0xfffff4fc = -2820.
2 Likes
The Eagle Post service always expect 8 hex digits - looking at the samples used for the original implementation his was always the case.
See page 17 -
It should be 0xfffff4fc, so missing ‘ff’ on left
Rainforest has acknowledged the bug and is fixing it. Should be completed by the end of the week or maybe next at the latest.
Yep. Ok thanks for that.
Looks like they have an inconsistency between these two specifications then. They’re working on in apparently.
Yep, thanks - can confirm they updated my ticket and said same. Hopefully wont take too long.
Received this a few days ago:
Unfortunately, we have still not still released the fix. Due to unforeseen circumstances, some other issues took more precedence. Rest assured, a ticket has been created for our developers to take a look at and they will work on this as soon as possible.
Ok, thank for the update.
Appears to be still-broken.
Fortunately, the WattVision integration with Rainforest Cloud still works, and I’m able to forward the data from WattVision to PVOutput. Is there a better way?
We can add an additional ‘ff’ on the PVOutput side as a workaround.
PVOutput should now be handling 6 hex digits starting with ff from the Eagle like 0xfff4fc by prepending ff, resulting in 0xfffff4fc instead of 0x00fff4fc
Hello @bankstownbloke,
I just received an email from Rainforest asking me to check to see if the PVOutput data was now correct 
I asked them when they pushed their update to production and let them know that you corrected their error by sign extending their 3-byte quanity.
Is it easy for you to verify that Rainforest is now pushing the true 4-byte quantity?