I'm familiar with port forwarding. 
The subject changed above and I got confused, however...so, yeah, that part shouldn't matter. Ignore me. 
1 Like
thanks which ip address would i use for the driver..
- the private ip in fl
- the ip of router in fl.
- the public ip in my net that i have configured the florida weatherstation to send to?
- or should i try the mac but i dont believe macs cross networks.
I was just thinking about that. I would expect the public IP of the condo, but I could be wrong ..
holy sh** that worked.. changed forwarding port to 8900 maybe some issue with such a large port on netgear orbi..
added firewall rule for 8900 in my router..
added port forwarding for 8900 to 39501 in my other wifi router..
added driver for ecowitt and public ip address for fl condo worked.. only problem is that it can change.. what happens if i use the dynamic ip name i have?
sensors resync'd and i now have the sensors from there in my hub so i can write rules to flag if the temps are out of wach or the wine coolers die.
thanks
3 Likes
If the traffic never gets to Hubitat, it won't matter. 
But if it does and you aren't sure, make it easy on yourself: just look at the hub logs for a "warn" log saying something like "no device found with DNI XYZ or ABC," where those are the MAC or IP (in hex) of the sensing device--that way you know it's what Hubitat sees. That's not the exact phrasing, but it will generate a log for all such traffic with no matching device, so you can use that to help.
2 Likes
It may also indicate if the Mac comes through, and if it does you may be able to use that instead of the public IP.
3 Likes
you mean hub events.. under logs.. i see nothing in there when i did have the driver with the wrong ip.. ie my public wifi router that is port forwarding.. will try mac and see
From the setup notes I think the warning just aopears in the regular logs page, against a device of "sys"
That looks like it is ok, at least in the way that parse is getting called on the device, it's not the warning from the HE hub about not knowing where to send the data. Could the error not be tied up in the time issue from the other day?
Or could it have been happening before and you only just turned on debug logging
ok mac not working which i figured.. macs dont normally cross network boundries.. changing back to ip .. maybe a change to the driver so i can use the name and a function that can be called to resolve the name to ip.. so i can write a rule to refresh the name to ip every week or so..
now back to open vpn and back on the florida ecowitt app through my phone to change fro 60 secs (had for testing) to 15 minutes.
1 Like
Yeah, Mirco did mention in the setup notes that the Mac did not work across VLan's even, so makes sense. Glad you got it working
thanks.. no go on 15 minutes.. max in app is 600 or 10 minutes.. oh well.
ya i will add a couple of parameters..
dynamic device ip name
and refresh time
and when there will resolve the name to ip and compare to the current ip and if different change it.. then reschedule to run on the refresh time.. Seems like an easy workaround as long as your remote router has a ddns name assigned.
Sounds good. Let me know if I can help, would be good to get it in the driver if that is ok.
BTW, which Mac did you try, the ecowitt one or your router in FL?
the ecowitt. i dont believe routers replace the mac addresses in packets..
I can try the mac address of the router.. and see ..
Only reason I ask is I know my router let's me change the Mac on my internet connection, wasn't sure if that also meant it was sent with all external traffic, or if it only related to the establishment of the connection.
@1a7dc3c08d03c361e0c5 - Sometimes it is nice to be wrong... (I'm referring to myself here....) The drivers can work with more than one Gateway, I can confirm they have been written to make use of the feature @bertabcd1234 described where the DNI is set to the mac or ip and this is used to direct the data to the right virtual device representing your EcoWitt Gateway.
2 Likes
Yeah, the more I looked at it I started to think the same thing that it would work. It is using a different MAC/IP address per "instance" if that's the right term. Still baffled as to where it knows to use port 39501. One might think it just monitors for any traffic coming from that MAC/IP but if you change 39501 on the Ecowitt side, it doesn't seem to work. Maybe that port designation is for the Ecowitt side? But then one might think why don't they auto fill it on that side? The answer is moot as long as it just works 
