I've done some more research on this. So far, I've had two 'events' of this. Both were only temporary. The reason that I notice them so easily is the yearly rain. When an 'event' happens, the yearly rain is returned as the correct value divided by ten. Weewx interprets this as counter wraparound, which is a normal thing. But when the 'event' ends and things go back to normal, weewx thinks rain has fallen. Of course, it hasn't really. But it shows up pretty obviously in the graphs. Some of the other data is missing too, because it becomes so out of range that weewx throws it away and logs it. But some of the data looks ok. The thing with the battery status is interesting because apparently the GW1000 temporarily thinks the sensor array is a WH26, whatever that is. That doesn't always happen, though. I've raised the issue with Lucy at Ecowitt. We're communicating about it, but this kind of thing isn't easy to track down. If I had a way to recreate the problem or if it would stay in this condition for long enough to troubleshoot it, it would be much better. I do believe that you have experienced this problem as well. I guess we'll just have to see if their engineers can think of something. And yes, I'm on 1.5.
wh26 is an old type of outdoor sensor, which is replaced by wh31, however GW1000 still supports detecting this sensor type. Do you have a wh26 sensor lying around? or you can confirm this by checking the sensor type listed on WS View APP? If the sensor was picked up before by GW1000, then GW1000 will pack this sensor for its ID, signal strength , battery level to the payload. However you can still validate the data: if data is sent with 0xFFFF ( ID) , 0xFF ( signal strength) , 0xFF ( batt ), it means the data is an invalid data, and should be filtered out.