According to the manual, it appears that it does this automatically when you register the WN32 on the device page. There is also no mention of setting the ID manually (like there is with the WN31's). The image in the manual shows an ID of 46 vs 60.
Also according to the manual, the uploads of the data to other sites is automatic from the gateway. Have you gone into WU or the Ecowitt website to verify the same or different is happening?
Again, this isn't an app setting. It is a setting on your gateway that is limited by Ecowitt.
Are you saying this because it shows under the WS90 device in HE? Or because you brought the WN32 sensor into a drastically different environment and verified that the temperature is the incorrect one? Again, per the site and the manual, it REPLACES those measurements. This to me indicates that might not turn off the WS90 device T&H reporting, but possibly puts the data in that location.
You are looking in the wrong place. The WN32 device does not control what happens to the data, it just sends it out.
If you look at:
You will see that T&H data has a priority list from what might be available.
"Data display priorities:
Outdoor temperature and humidity data: WN32 > WS90 > WS80 > WS69"
Here you can clearly see that data from the WN32 has a higher priority than data from the WS90. Thus, the WN32 data should "override" the data from the WS90 when both are present.
When I referred to ID 60, that was used in the setup for the HP2560. I don't remember which forum I got this from, but I did get help in setting up my Ecowitt weather station. You can see on page 62 of the HP2560 manual, that you can "Make console receiving data from a pre-defined sensor ID". This is where I entered the "60" under "T&H".
I have my Ecowitt app on my Android phone set up with 2 different configurations, one shows the data using the WN32 replacing the T&H of the WS90, the other shows only the WS90 data. I'm currently showing a 0.5 F. degree difference in temperature and a 8% difference in humidity between the two. From these, I can easily see that the T&H data reaching HE is from the WS90, not the WN32.
I believe ecowitt sensors can be paired to more than one gateway.
My understanding is that @Automation_Ken has their sensors paired to the ecowitt WiFi gateway, which I presume is the GW1100), and also the HP2560_C. But the data substitution is only configured on the HP2560_C. If that is correct, then the solution would be to send data from the HP2560_C to Hubitat. Rather than data from the GW1100.
I can't push data from the HP2560 because it requires a special protocol to talk to my Cumulus weather software. If I change the settings to match HE, I loose the connection to Cumulus. This is why I bought the GW1200.
When I connect the GW1200 to HE, that is where I get the error message from HE about not allowing two outdoor sensors and only the WS90 showing up.
No such luck. My guess is that it has to be done on the Hubitat side. My reasoning is that if Hubitat knew enough to tell me that I had two outdoor sensors, then it should know what the extra sensor is transmitting, but I may be wrong.
The app is a direct local connection that sees all the channels. I am talking about either the Ecowitt web page (station on the web), or the WU page on the web. Trying to see what the gateway is pushing out.
Weather Underground and CWOP is fed from my Cumulus weather software. I also host my own weather page which is also fed from Cululus. In that Cumulus gets all its data from the HP2560 (which uses the WN32 for T&H), all information going out into the world is based on the WN32. I do not have an Ecowitt web page because I don't want any of my data going to China, or to any other company.
I might need a summary of where things got to with the recent conversations. i.e. If you are still having issues with making the additional outdoor sensor working, etc. If so, could you please send me a PM with where things are at. I would also need (eventually) a copy of the data feed, but need to find the time to list the steps required to get this (should be just turning on debug/trace logging on the gateway and grabbing the log of the data feed, but I want to confirm...).
Thanks again to the great support I receive for this integration from people like @kahn-hubitat, @marktheknife , @dJOS , @aaiyar (and others, obviously) and a special shout-out to @tray_e for recent efforts in this space.
