Rainforest EAGLE-200 Energy Gateway - Does you have one?

evanrich · September 11, 2018, 7:22am

no problem! I’m pretty swamped with work, but if there’s any interest in analyzing the other data I’ll capture it using tcpdump and see what other info the eagle spits out. I have an Eagle-100 not 200 so not sure if the 200 displays any additional data, but i think the important stuff is covered so far.

pruchai · October 5, 2018, 7:12pm

@evanrich, great work, man! saved me lots of time.

Is pricing information Utility-dependent or is it there by default? I am having trouble pulling rates/tier on my Eagle-200, while instantaneous demands works just fine.

evanrich · October 5, 2018, 9:22pm

It might be utility dependent. If you can run tcpdump -A to capture the ascii data coming out of the eagle, paste it here so I can see. There should be a " block or something that it sends, if it gets any from your meter.

Actually, if you wouldn’t mind… Let me know your Utility provider, and if any other info is missing send me a packet capture of whatever is missing (from TCPDUMP) and I can try to modify the source code. I talked with the original author and he gave permission to modify as needed if it’s helpful to me or others, so I’ll see what I can do for you.

pruchai · October 5, 2018, 11:13pm

Provider in SDG&E.

But tcpdump shows nothing but DeviceInfo,InstantaneousDemand and CurrentSummation. I guess I need figure out how to pull pricing and rate info from SDG&E website…

But let me ask you this… how often does the rate in tier get pushed? On continuous basis or just when the tier changes?

evanrich · October 5, 2018, 11:39pm

My Eagle-100 publishes price every ~30 seconds. If I TCDUMP the incoming traffic from eagle, I get a block like this:

<PriceCluster>
  <DeviceMacId>00112233445566778899</DeviceMacId>
  <MeterMacId>00112233445566778899</MeterMacId>
  <TimeStamp>0x234ab19e</TimeStamp>
  <Price>0x0000ae05</Price>
  <Currency>0x0348</Currency>
  <TrailingDigits>0x05</TrailingDigits>
  <Tier>0x03</Tier>
  <StartTime>0x234aa970</StartTime>
  <Duration>0x00f0</Duration>
  <RateLabel>Peak</RateLabel>
  <Port>/dev/ttySP0</Port>
</PriceCluster>

</rainforest>

in the span of ~10 minutes i got this:

sudo tcpdump -i eno1 host 192.168.xxx.yyy -A |grep PriceCluster
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>
<PriceCluster>
</PriceCluster>

I chose not to convery the currency from ISO code to USD/etc since I assume everyone didn’t care/want it. Tier for me (PG&E) converts to one of three things: Off peak, partial-peak, Peak, which then also carries 3 price ranges. Right now it’s peak, so that price (ae05) translates to “44549”, trailing digits means move the decimal 5 places to the left so i get 0.44549 $ (currency code 0348) per kWh. (yeah…sucks!). the "Duration of “f0” translates to 240… which i’m guessing might be minutes? that would be ~4 hours, which seems to approximate what my peak period is.

Edit: Just for record, here are the other blocks I get from PG&E’s meter:

If anyone’s interested I might try exposing “0x64” from Network info, might be able to graph that in grafana…I’m assuming link between meter and eagle. Current value of 0x64 is 100…not sure the units…100%? I tried opening my garage door to remove barrier between meter (outside) and the eagle (in my server rack inside the garage and the link strength didn’t change, so not sure if this is a useful metric after all.

poldim · October 9, 2018, 9:30pm

I’m interested!

I’m finally getting some time after my move to set this bad boy up. So I have the newer one with 5 lights. It seems like they have the removed the local GUI on the device - is this correct? It’s a simple page that loads a single javascript file that is 47k lines: RFA · GitHub

I did find the cloud portal has a CLOUD tab where you can configure another destination. However, I don’t like the fact that you have to send your data to their cloud. Any solution to this?

Maybe if the configuration is a one-time thing, I could block outward access in my firewall.

evanrich · October 10, 2018, 12:26am

I don’t have the 200 (don’t really see much of a difference between the 200 and the 100 TBH), so can’t tell you, but the cloud tab seems like the same thing from the 100. I would just figure out the destination and block it at your firewall level (or block all outbound from that IP to any destination except your eagle-to-mqtt converter

Reading reviews on the 200, seems like it’s a lot harder to set up than the 100.

pruchai · October 10, 2018, 7:27am

I haven’t owned the 100, but 200 is a complete piece… I couldn’t get that thing to connect to my meter no matter what i did. wasted an entire holiday weekend on it. turned out the MAC address printed on the label were wrong. Basically i now have a Cloud ID and 2 sets of MACs and Install codes. Because it registered on the portal with whatever printed on the label and it was registered with another set with the Utility. Then it would randomly disconnect from the portal and I had to contact support again.

This thing is talking to the cloud via OpenVPN tunnel. I had to isolate it on its own VLAN, because their support just logins into the device whenever they need to. I don’t want them to have any access to my internal network for no reason whatsoever.

Old Web interface is gone. Not the only thing you can do via web UI is to enable/disable wifi/ethernet.

Local API does not seem to work any longer either, so all 3rd party data collection like HA has to be configured via their portal.

And to top it all off, this is in their React.js code

var ReactPropTypesSecret = 'SECRET_DO_NOT_PASS_THIS_OR_YOU_WILL_BE_FIRED';

estebanp · October 26, 2018, 4:57am

Hi all.
I have the eagle100. I have been using it in OH2 with the “local API” for two weeks without it to hang.
I am using the local rest API but with a twist. I took a look to the js scripts in the local Rainforest web page. It turns out they are using a different entry point and commands.
This is what I am doing in HA:

sensor:
- platform: rest
  name: Energy instant demand
  resource: http://192.168.XX.XXX/cgi-bin/cgi_manager
  method: POST
  payload: '{ <LocalCommand><Name>get_usage_data</Name><MacId>0xXXXXXXXXXXXXXXXX</MacId></LocalCommand> }'
  value_template: '{{ value_json["demand"] | float }}'
  unit_of_measurement: 'kW'

This is an example of the response:

{"meter_status":"Connected",
"demand":"0.3820",
"demand_units":"kW",
"demand_timestamp":"1539380816",
"summation_received":"0.000",
"summation_delivered":"119179.547",
"summation_units":"kWh",
"price":"-1.0000",
"price_units":"840",
"message_timestamp":"946684800",
"message_confirmed":"N",
"message_confirm_required":"N",
"message_id":"0",
"message_queue":"active",
"message_read":"Y",
"threshold_upper_demand":"11.352000",
"threshold_lower_demand":"-2.000000",
"fast_poll_frequency":"0x00",
"fast_poll_endtime":"0x00000000",
"start_time":"0",
"end_time":"0",
"currency":"840",
"consumption":"0.000",
"num_blocks":"0",
"unit":"kWh"}

adamg · November 30, 2018, 8:26pm

I have been considering getting one of these… Unfortunately cant get the 100 anymore. @pruchai, did you eventually get the 200 talking or is it a complete waste of $?

poldim · December 1, 2018, 5:11pm

I haven’t spent enough time getting it to work with this docker, but it’s connected to my meter and shows up on their portal just fine.

kozoke · December 28, 2018, 3:35am

Hi, Just circling around on this again now that PG&E has configured my new temp-pole meter. I’m not sure if any other changes have been made but I able to connect to the docker container and it appears to be sending from the eagle to the docker container but i’m not getting any mqtt messagse posted to power/elec/Home
I’m using the python3 tag but no luck

Any other suggestions? Not getting anything in the log either.
Thanks!

evanrich · December 28, 2018, 9:02pm

did you set up the webserver address in the eagle screen to point to the ip of the container? you should have something like this:

Assuming you’re running the container not in kubernetes but in docker, can you do something like this on the host using tcpdump

tcpdump -i any host <IP of eagle>

for example, here’s the output on my k8s host who’s ip i have in the screenshot above (192.168.1.20):

evan@mira-a:/srv/k8s/pms$ sudo tcpdump -i any host 192.168.1.201
[sudo] password for evan:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:01:23.834709 IP 192.168.1.201.53528 > mira-a.home.31242: Flags [S], seq 790001457, win 5840, options [mss 1460,sackOK,TS val 4617350 ecr 0,nop,wscale 2], length 0
13:01:23.834824 IP 10.32.0.231.22042 > 192.168.1.201.53528: Flags [S.], seq 1049822638, ack 790001458, win 26480, options [mss 1336,sackOK,TS val 2111464065 ecr 4617350,nop,wscale 7], length 0
13:01:23.834836 IP mira-a.home.31242 > 192.168.1.201.53528: Flags [S.], seq 1049822638, ack 790001458, win 26480, options [mss 1336,sackOK,TS val 2111464065 ecr 4617350,nop,wscale 7], length 0
13:01:23.835087 IP 192.168.1.201.53528 > mira-a.home.31242: Flags [.], ack 1, win 1460, options [nop,nop,TS val 4617350 ecr 2111464065], length 0
13:01:23.835930 IP 192.168.1.201.53528 > mira-a.home.31242: Flags [P.], seq 1:710, ack 1, win 1460, options [nop,nop,TS val 4617350 ecr 2111464065], length 709
13:01:23.835950 IP 10.32.0.231.22042 > 192.168.1.201.53528: Flags [.], ack 710, win 218, options [nop,nop,TS val 2111464066 ecr 4617350], length 0
13:01:23.835957 IP mira-a.home.31242 > 192.168.1.201.53528: Flags [.], ack 710, win 218, options [nop,nop,TS val 2111464066 ecr 4617350], length 0
13:01:24.274323 IP 192.168.1.201.53531 > mira-a.home.31242: Flags [S], seq 798417568, win 5840, options [mss 1460,sackOK,TS val 4617394 ecr 0,nop,wscale 2], length 0
13:01:24.274528 IP 10.32.0.231.22042 > 192.168.1.201.53531: Flags [S.], seq 2285127417, ack 798417569, win 26480, options [mss 1336,sackOK,TS val 2111464505 ecr 4617394,nop,wscale 7], length 0
13:01:24.274563 IP mira-a.home.31242 > 192.168.1.201.53531: Flags [S.], seq 2285127417, ack 798417569, win 26480, options [mss 1336,sackOK,TS val 2111464505 ecr 4617394,nop,wscale 7], length 0
13:01:24.274893 IP 192.168.1.201.53531 > mira-a.home.31242: Flags [.], ack 1, win 1460, options [nop,nop,TS val 4617394 ecr 2111464505], length 0
13:01:24.275792 IP 192.168.1.201.53531 > mira-a.home.31242: Flags [P.], seq 1:763, ack 1, win 1460, options [nop,nop,TS val 4617394 ecr 2111464505], length 762
13:01:24.275871 IP 10.32.0.231.22042 > 192.168.1.201.53531: Flags [.], ack 763, win 219, options [nop,nop,TS val 2111464506 ecr 4617394], length 0
13:01:24.275892 IP mira-a.home.31242 > 192.168.1.201.53531: Flags [.], ack 763, win 219, options [nop,nop,TS val 2111464506 ecr 4617394], length 0
13:01:24.277453 IP 10.32.0.231.22042 > 192.168.1.201.53531: Flags [P.], seq 1:18, ack 763, win 219, options [nop,nop,TS val 2111464508 ecr 4617394], length 17
13:01:24.277493 IP mira-a.home.31242 > 192.168.1.201.53531: Flags [P.], seq 1:18, ack 763, win 219, options [nop,nop,TS val 2111464508 ecr 4617394], length 17
13:01:24.277715 IP 192.168.1.201.53531 > mira-a.home.31242: Flags [.], ack 18, win 1460, options [nop,nop,TS val 4617394 ecr 2111464508], length 0
13:01:24.277801 IP 10.32.0.231.22042 > 192.168.1.201.53531: Flags [P.], seq 18:156, ack 763, win 219, options [nop,nop,TS val 2111464508 ecr 4617394], length 138
13:01:24.277829 IP mira-a.home.31242 > 192.168.1.201.53531: Flags [P.], seq 18:156, ack 763, win 219, options [nop,nop,TS val 2111464508 ecr 4617394], length 138
13:01:24.277852 IP 10.32.0.231.22042 > 192.168.1.201.53531: Flags [F.], seq 156, ack 763, win 219, options [nop,nop,TS val 2111464508 ecr 4617394], length 0
13:01:24.277882 IP mira-a.home.31242 > 192.168.1.201.53531: Flags [F.], seq 156, ack 763, win 219, options [nop,nop,TS val 2111464508 ecr 4617394], length 0
13:01:24.278087 IP 192.168.1.201.53531 > mira-a.home.31242: Flags [.], ack 156, win 1728, options [nop,nop,TS val 4617394 ecr 2111464508], length 0
13:01:24.278838 IP 192.168.1.201.53531 > mira-a.home.31242: Flags [F.], seq 763, ack 157, win 1728, options [nop,nop,TS val 4617394 ecr 2111464508], length 0
13:01:24.278907 IP 10.32.0.231.22042 > 192.168.1.201.53531: Flags [.], ack 764, win 219, options [nop,nop,TS val 2111464509 ecr 4617394], length 0
13:01:24.278937 IP mira-a.home.31242 > 192.168.1.201.53531: Flags [.], ack 764, win 219, options [nop,nop,TS val 2111464509 ecr 4617394], length 0

this proves traffic is coming to the machine from the eagle. If you don’t see any output here, then your eagle isn’t sending to the container. you could add a -A to this as well to see full text output, which will give you something like this

13:03:30.667338 IP 192.168.1.201.39859 > mira-a.home.31242: Flags [P.], seq 1:659, ack 1, win 1460, options [nop,nop,TS val 4630034 ecr 2111590899], length 658
E...=.@[email protected]
.......=.....V.....
.F..}.Q.POST / HTTP/1.1
Host: 192.168.1.20:31242
Accept: */*
From: [email protected]
User-Agent: Raven Uploader/v1
Content-Type: application/xml
Content-Length: 478

<?xml version="1.0"?><rainforest macId="redacted" version="undefined" timestamp="1546031007s">
<NetworkInfo>
  <DeviceMacId>redacted</DeviceMacId>
  <CoordMacId>redacted</CoordMacId>
  <Status>Connected</Status>
  <Description>Successfully Joined</Description>
  <ExtPanId>redacted</ExtPanId>
  <Channel>25</Channel>
  <ShortAddr>0x8738</ShortAddr>
  <LinkStrength>0x64</LinkStrength>
  <Port>/dev/ttySP0</Port>
</NetworkInfo>

rgabrlson · December 31, 2018, 2:38pm

Pretty sure Im having same issue. Just set this up in docker, and appears Im getting connection from Eagle to the server, but nothing posted to MQTT. I believe its has to do with the MQTT parameters being passed over properly but havent had time to dig.

OSError: [Errno 113] Host is unreachable

Traceback (most recent call last):

File “/app/src/bin/tHome-eagle.py”, line 114, in

client = T.broker.connect( c.configDir, log )

File “/app/src/python/tHome/broker/connect.py”, line 37, in connect

client.connect( cfg.host, cfg.port, cfg.keepAlive )

File “/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py”, line 839, in connect

return self.reconnect()

File “/usr/local/lib/python3.7/site-packages/paho/mqtt/client.py”, line 962, in reconnect

sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))

File “/usr/local/lib/python3.7/socket.py”, line 727, in create_connection

raise err

File “/usr/local/lib/python3.7/socket.py”, line 716, in create_connection

sock.connect(sa)

OSError: [Errno 113] Host is unreachable

evanrich · December 31, 2018, 6:05pm

Did you define the variables? I’ll pull up the repo in a bit, but there are defaults for my system inside, you need to override with environmental variables. Give me a bit to post

kozoke · December 31, 2018, 7:01pm

Hi,
Thanks again for the help! I ran the tcp dump and saw the traffic coming across. That looked ok. When I ran it with the -A option, I see more dtails but I do not see the formatted above. Not sure if that is a contributing factor? Note - I am also using port 22042 as that is in the docker config file vs your screenshort above showing 31242 (is this a possible issue?) I did try 31242 and did not connect.

I’m also not seeing any mqtt traffic - power/elec/#

Let us know how we can help trouble shoot. @evanrich - really appreciate your help!

kozoke · December 31, 2018, 7:18pm

Yes, I defined variables in the docker command as follows:
‘’’
docker run --name py-eagle-mqtt-3 -d
–restart=always
-e “MQTT_BROKER_IP=192.168.###.###”
-p 22042:22042
-e “MQTT_BROKER_PORT=1883”
-e “MQTT_USER=”
-e “MQTT_PASSWORD=”
evanrich/py-eagle-mqtt:python3
‘’’
One possible (self inficted) issue - with the changes to mqtt in recent HA versions, I did add a user-id and password - so I addresssed that but stil no mqtt messages.

Let us know you have additional suggestions. Thanks!

evanrich · December 31, 2018, 10:51pm

that looks correct. Here’s my deployment.yaml file in K8s:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: py-eagle-mqtt
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: py-eagle-mqtt
    spec:
      containers:
      - name: py-eagle-mqtt
        image: evanrich/py-eagle-mqtt:python3
        env:
        - name: MQTT_BROKER_IP
          value: '192.168.1.20'
        - name: MQTT_BROKER_PORT
          value: '31333'
        ports:
        - name: py-eagle
          containerPort: 22042
        readinessProbe:
          tcpSocket:
            port: py-eagle
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          tcpSocket:
            port: py-eagle
          initialDelaySeconds: 15
          periodSeconds: 20

That would translate into docker-speak as:

docker run --name py-eagle-mqtt -d 
–restart=always 
-e “MQTT_BROKER_IP=192.168.1.20” 
-p 22042:22042 
-e “MQTT_BROKER_PORT=31333” 
evanrich/py-eagle-mqtt:python3

the 31333 is a nodeport, basically every kubernetes node listens on 31333 and sends it to 1883 in the mqtt container…here’s that service for reference:

apiVersion: v1
kind: Service
metadata:
  name: mqtt
spec:
  selector:
    app: mqtt
  type: NodePort
  ports:
  - name: mqtt
    port: 1883
    targetPort: 1883
    nodePort: 31333
  - name: mqtt-bridge
    port: 8080
    targetPort: 8080
    nodePort: 31334
---

but basically, any MQTT traffic i send to 192.168.1.20:31333 goes to port 1883 in the broker.

looking at tHome’s code (with my modifications), here are the variables available, with their defaults:

host = os.getenv('MQTT_BROKER_IP', '192.168.1.20')
port = os.getenv('MQTT_BROKER_PORT', 1883)
user = os.getenv('MQTT_USER', None)
password = os.getenv('MQTT_PASS', None)
keepAlive = os.getenv('KEEPALIVE', 60)

The container is hardcoded to serve on 22042:
httpPort = 22042

and I’m currently running this, with it working, so I’m 99.999% sure it’s not the code. Here’s what we do know:

You’re getting TCPDUMP data on your host, which means that the eagle is successfully sending stuff to your host (whether that’s garbage or not, we don’t know yet)
you’ve got correct copy of the code running, since I’m running the same thing, so it’s not likely the container.

Here’s what I would do to next-step this.

If you could, can you send me a .pcap from your tcpdump of the eagle? If it contains any useful data from the eagle, it might have your eagle’s MAC, zigbee MAC, and possibly the MAC of your meter. Fairly safe, but up to you. IF you don’t want to share the PCAP, then you could paste it here (sanitize out your MACs). This will help see what the eagle is sending.
Do a tcpdump again, but this time look at the output . tcpdump -i any port 1883

Also, what IP is your broker listneing on? Are you using the home-assistant built in mqtt broker? I’m running my own.

 containers:
      - name: mqtt
        image: matteocollina/mosca:v2.8.3
        volumeMounts:
        - name: dockerdata
          subPath: mqtt
          mountPath: /db
        env:
        - name: PUID
          value: '1001'
        - name: PGID
          value: '1001'
        - name: TZ
          value: 'America/Los_Angeles'
        ports:
        - name: mqtt
          containerPort: 1883

Perhaps that could be the issue, as im not sure the Username/password options work.

TL;DR:

Lets see what first is coming out of the eagle. The code from tHome is pretty specific in how it dissects data, and perhaps the eagle 200 sends data in a different format than the eagle-100, which would render this moot, since the code would never be able to parse it. If that’s the case, I can try and modify the code to work on eagle 100 and 200’s, but I’d need to see like a 1-3 minute capture of your eagle-200 output.

I’m not a python developer, but I can figure things out pretty well, so assuming I can get a good source dump of whatever eagle-200 sends out, i can probably modify things to work for you.

kozoke · January 1, 2019, 1:31am

TCP dump of port 1883 below. Note - I changed my hassio address to — ha — and I changed the IP of my docker host to — docker host — otherwise, it is the same.

Re: MQTT broker, I use the hassio mosquitto add-on - it runs on IP 192.168.0.151 and is working well with many esphomeyaml and other devices in my home.

I am using an eagle 100 series. and (confidingly) your code worked just fine a few months back… Odd…

Let me know if you have other thoughts or want the host dump - I can sanitize that too.

Thanks again
‘’’
kozoke@U16HA2:~$ sudo tcpdump -i any port 1883
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
17:17:50.624867 IP 172.17.0.5.57104 > .1883: Flags [S], seq 346888470, win 29200, options [mss 1460,sackOK,TS val 643930507 ecr 0,nop,wscale 7], length 0
17:17:50.624880 IP 172.17.0.5.57104 > .1883: Flags [S], seq 346888470, win 29200, options [mss 1460,sackOK,TS val 643930507 ecr 0,nop,wscale 7], length 0
17:17:50.624893 IP .57104 > .1883: Flags [S], seq 346888470, win 29200, options [mss 1460,sackOK,TS val 643930507 ecr 0,nop,wscale 7], length 0
17:17:50.625494 IP .1883 > .57104: Flags [S.], seq 2636669594, ack 346888471, win 28960, options [mss 1460,sackOK,TS val 257359146 ecr 643930507,nop,wscale 7], length 0
17:17:50.625505 IP .1883 > 172.17.0.5.57104: Flags [S.], seq 2636669594, ack 346888471, win 28960, options [mss 1460,sackOK,TS val 257359146 ecr 643930507,nop,wscale 7], length 0
17:17:50.625507 IP .1883 > 172.17.0.5.57104: Flags [S.], seq 2636669594, ack 346888471, win 28960, options [mss 1460,sackOK,TS val 257359146 ecr 643930507,nop,wscale 7], length 0
17:17:50.625535 IP 172.17.0.5.57104 > .1883: Flags [.], ack 1, win 229, options [nop,nop,TS val 643930507 ecr 257359146], length 0
17:17:50.849507 IP .1883 > .57104: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257359168 ecr 643930509], length 4
17:17:50.849539 IP .1883 > 172.17.0.5.57104: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257359168 ecr 643930509], length 4
17:17:50.849543 IP .1883 > 172.17.0.5.57104: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257359168 ecr 643930509], length 4
17:17:50.849592 IP 172.17.0.5.57104 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643930563 ecr 257359168], length 0
17:17:50.849597 IP 172.17.0.5.57104 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643930563 ecr 257359168], length 0
17:17:50.849602 IP .57104 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643930563 ecr 257359168], length 0
17:17:50.849609 IP .1883 > .57104: Flags [F.], seq 5, ack 27, win 227, options [nop,nop,TS val 257359168 ecr 643930509], length 0
17:17:50.849958 IP 172.17.0.5.57104 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643930564 ecr 257359168], length 0
17:17:50.849962 IP 172.17.0.5.57104 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643930564 ecr 257359168], length 0
17:17:50.849966 IP .57104 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643930564 ecr 257359168], length 0
17:17:50.850449 IP .1883 > .57104: Flags [.], ack 28, win 227, options [nop,nop,TS val 257359168 ecr 643930564], length 0
17:17:50.850457 IP .1883 > 172.17.0.5.57104: Flags [.], ack 28, win 227, options [nop,nop,TS val 257359168 ecr 643930564], length 0
17:17:50.850458 IP .1883 > 172.17.0.5.57104: Flags [.], ack 28, win 227, options [nop,nop,TS val 257359168 ecr 643930564], length 0
17:19:50.858911 IP 172.17.0.5.51199 > .1883: Flags [S], seq 773371644, win 29200, options [mss 1460,sackOK,TS val 643960566 ecr 0,nop,wscale 7], length 0
17:19:50.858926 IP 172.17.0.5.51199 > .1883: Flags [S], seq 773371644, win 29200, options [mss 1460,sackOK,TS val 643960566 ecr 0,nop,wscale 7], length 0
17:19:50.858938 IP .51199 > .1883: Flags [S], seq 773371644, win 29200, options [mss 1460,sackOK,TS val 643960566 ecr 0,nop,wscale 7], length 0
17:19:50.859559 IP .1883 > .51199: Flags [S.], seq 2723851698, ack 773371645, win 28960, options [mss 1460,sackOK,TS val 257371169 ecr 643960566,nop,wscale 7], length 0
17:19:50.859576 IP .1883 > 172.17.0.5.51199: Flags [S.], seq 2723851698, ack 773371645, win 28960, options [mss 1460,sackOK,TS val 257371169 ecr 643960566,nop,wscale 7], length 0
17:19:50.859579 IP .1883 > 172.17.0.5.51199: Flags [S.], seq 2723851698, ack 773371645, win 28960, options [mss 1460,sackOK,TS val 257371169 ecr 643960566,nop,wscale 7], length 0
17:19:50.859608 IP 172.17.0.5.51199 > .1883: Flags [.], ack 1, win 229, options [nop,nop,TS val 643960566 ecr 257371169], length 0
17:19:50.872407 IP 172.17.0.5.51199 > .1883: Flags [P.], seq 1:27, ack 1, win 229, options [nop,nop,TS val 643960569 ecr 257371169], length 26
17:19:50.872415 IP 172.17.0.5.51199 > .1883: Flags [P.], seq 1:27, ack 1, win 229, options [nop,nop,TS val 643960569 ecr 257371169], length 26
17:19:50.872427 IP .51199 > .1883: Flags [P.], seq 1:27, ack 1, win 229, options [nop,nop,TS val 643960569 ecr 257371169], length 26
17:19:50.872984 IP .1883 > .51199: Flags [.], ack 27, win 227, options [nop,nop,TS val 257371171 ecr 643960569], length 0
17:19:50.873002 IP .1883 > 172.17.0.5.51199: Flags [.], ack 27, win 227, options [nop,nop,TS val 257371171 ecr 643960569], length 0
17:19:50.873006 IP .1883 > 172.17.0.5.51199: Flags [.], ack 27, win 227, options [nop,nop,TS val 257371171 ecr 643960569], length 0
17:19:51.082906 IP .1883 > .51199: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257371192 ecr 643960569], length 4
17:19:51.082937 IP .1883 > 172.17.0.5.51199: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257371192 ecr 643960569], length 4
17:19:51.082942 IP .1883 > 172.17.0.5.51199: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257371192 ecr 643960569], length 4
17:19:51.082954 IP .1883 > .51199: Flags [F.], seq 5, ack 27, win 227, options [nop,nop,TS val 257371192 ecr 643960569], length 0
17:19:51.082960 IP .1883 > 172.17.0.5.51199: Flags [F.], seq 5, ack 27, win 227, options [nop,nop,TS val 257371192 ecr 643960569], length 0
17:19:51.082960 IP .1883 > 172.17.0.5.51199: Flags [F.], seq 5, ack 27, win 227, options [nop,nop,TS val 257371192 ecr 643960569], length 0
17:19:51.083037 IP 172.17.0.5.51199 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643960622 ecr 257371192], length 0
17:19:51.083402 IP 172.17.0.5.51199 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643960622 ecr 257371192], length 0
17:19:51.083407 IP 172.17.0.5.51199 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643960622 ecr 257371192], length 0
17:19:51.083413 IP .51199 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643960622 ecr 257371192], length 0
17:19:51.083924 IP .1883 > .51199: Flags [.], ack 28, win 227, options [nop,nop,TS val 257371192 ecr 643960622], length 0
17:19:51.083935 IP .1883 > 172.17.0.5.51199: Flags [.], ack 28, win 227, options [nop,nop,TS val 257371192 ecr 643960622], length 0
17:19:51.083937 IP .1883 > 172.17.0.5.51199: Flags [.], ack 28, win 227, options [nop,nop,TS val 257371192 ecr 643960622], length 0
17:21:51.085586 IP 172.17.0.5.58974 > .1883: Flags [S], seq 332950993, win 29200, options [mss 1460,sackOK,TS val 643990622 ecr 0,nop,wscale 7], length 0
17:21:51.085600 IP 172.17.0.5.58974 > .1883: Flags [S], seq 332950993, win 29200, options [mss 1460,sackOK,TS val 643990622 ecr 0,nop,wscale 7], length 0
17:21:51.085615 IP .58974 > .1883: Flags [S], seq 332950993, win 29200, options [mss 1460,sackOK,TS val 643990622 ecr 0,nop,wscale 7], length 0
17:21:51.086225 IP .1883 > .58974: Flags [S.], seq 3454040118, ack 332950994, win 28960, options [mss 1460,sackOK,TS val 257383192 ecr 643990622,nop,wscale 7], length 0
17:21:51.086235 IP .1883 > 172.17.0.5.58974: Flags [S.], seq 3454040118, ack 332950994, win 28960, options [mss 1460,sackOK,TS val 257383192 ecr 643990622,nop,wscale 7], length 0
17:21:51.086240 IP .1883 > 172.17.0.5.58974: Flags [S.], seq 3454040118, ack 332950994, win 28960, options [mss 1460,sackOK,TS val 257383192 ecr 643990622,nop,wscale 7], length 0
17:21:51.086267 IP 172.17.0.5.58974 > .1883: Flags [.], ack 1, win 229, options [nop,nop,TS val 643990623 ecr 257383192], length 0
17:21:51.328944 IP .1883 > .58974: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257383216 ecr 643990623], length 4
17:21:51.328975 IP .1883 > 172.17.0.5.58974: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257383216 ecr 643990623], length 4
17:21:51.328980 IP .1883 > 172.17.0.5.58974: Flags [P.], seq 1:5, ack 27, win 227, options [nop,nop,TS val 257383216 ecr 643990623], length 4
17:21:51.329016 IP 172.17.0.5.58974 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643990683 ecr 257383216], length 0
17:21:51.329020 IP 172.17.0.5.58974 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643990683 ecr 257383216], length 0
17:21:51.329027 IP .58974 > .1883: Flags [.], ack 5, win 229, options [nop,nop,TS val 643990683 ecr 257383216], length 0
17:21:51.329094 IP .1883 > .58974: Flags [F.], seq 5, ack 27, win 227, options [nop,nop,TS val 257383216 ecr 643990623], length 0
17:21:51.329455 IP 172.17.0.5.58974 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643990683 ecr 257383216], length 0
17:21:51.329460 IP 172.17.0.5.58974 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643990683 ecr 257383216], length 0
17:21:51.329466 IP .58974 > .1883: Flags [F.], seq 27, ack 6, win 229, options [nop,nop,TS val 643990683 ecr 257383216], length 0
17:21:51.329854 IP .1883 > .58974: Flags [.], ack 28, win 227, options [nop,nop,TS val 257383216 ecr 643990683], length 0
17:21:51.329864 IP .1883 > 172.17.0.5.58974: Flags [.], ack 28, win 227, options [nop,nop,TS val 257383216 ecr 643990683], length 0
17:21:51.329866 IP .1883 > 172.17.0.5.58974: Flags [.], ack 28, win 227, options [nop,nop,TS val 257383216 ecr 643990683], length 0

‘’’

evanrich · January 1, 2019, 8:47am

Thanks, sorry I think I forgot to mention the -A option (for Ascii output). can you re-run it using something like
tcpdump -i any src host <ip of your Eagle-100> -A

you should get text output that every 10 seconds or so shows stuff. I ran the same command you did though and it looks the same on my machine, that is to say it looks like stuff is working right. Also, I haven’t changed the code since september (and have even re-deployed my container, so i know the code works).

The fact that I see traffic going to port 1883 tells me it’s passing data to your MQTT broker, so I think it might be a Home assistant thing, but lets see.

Actually, can you give two outputs:

to see what the eagle is sending in:
tcpdump -i any src host <ip of your Eagle-100> -A

to see what the py-eagle-mqtt container is sending to your mqtt broker:
tcpdump -i any port 1883 -A or tcpdump -i any port 1883 and host <ip of your mqtt broker> -A

needs to be run as root btw. Feel free to strip out any IPs/MACs, etc…I’m just interested in seeing if the XML tags show up, namely something like this:

00:36:58.878970 IP 192.168.1.201.42380 > mira-a.home.31242: Flags [P.], seq 0:709, ack 1, win 1460, options [nop,nop,TS val 150247 ecr 2412404873], length 709
E...Rj@[email protected]
e...U(H............
..J...`.POST / HTTP/1.1
Host: 192.168.1.20:31242
Accept: */*
From: [email protected]
User-Agent: Raven Uploader/v1
Content-Type: application/xml
Content-Length: 529

<?xml version="1.0"?><rainforest macId="0xMAC" version="undefined" timestamp="1546331816s">
<InstantaneousDemand>
  <DeviceMacId>0xMAC</DeviceMacId>
  <MeterMacId>0xMAC</MeterMacId>
  <TimeStamp>0x23bde328</TimeStamp>
  <Demand>0x000322</Demand>
  <Multiplier>0x00000001</Multiplier>
  <Divisor>0x000003e8</Divisor>
  <DigitsRight>0x03</DigitsRight>
  <DigitsLeft>0x0f</DigitsLeft>
  <SuppressLeadingZero>Y</SuppressLeadingZero>
  <Port>/dev/ttySP0</Port>
</InstantaneousDemand>

</rainforest>

This is using the exact same container (just re-deployed to make sure). As a side thought, have you tried power-cycling your eagle-100? Before this, I was polling the Eagle every 10 seconds using API calls, and it would cause the eagle to lock up…I don’t think that’s the case here since your tcpdump seems to show activity (although to 1883, your broker), but maybe power-cycling the eagle might help too. The TCPDUMPs will show me what is coming out of the eagle to py-eagle-mqtt, and what py-eagle-mqtt is sending on to your mqtt broker.

If you’d prefer to email me to keep logs out of here or what not, my email is

evanrich81[at]geeeeemail[dot]com

. that is not how the provider is spelled obviously (use common spelling), just don’t want any scrapers/bots pulling it sorry for the late reply, forums weren’t working from my mobile device earlier.