smileyw

You are correct. I accidentally restarted PG3 between all that, so everything updated. I thought I grabbed it in time, but I didn't. I will wait until it rains again post screenshots and send you the logs. But there is something not updating until restart. I will also play with which thing needs to be restarted in order for it to update. (i.e. The node, PG3, or the eISY.)

I have been noticing this problem for a while, but I am having trouble figuring out the source, I have narrowed it down a bit, and now at least see where the disconnect is (though I don;t know what the problem is...) Data in the ISY (eISY) isn't populating from the plug-in until I reboot. Here are two current screenshots to prove my point. You can see weekly and monthly are quite a bit off. They will not change on the ISY side until I reboot. I haven't rebooted yet in case there are any potential logs that would helpful. You can see that the data in the ISY is old. If I reboot, it will update, but then it will be off again until the next reboot. As far as I know, everything is on the latest versions of everything.

Brining up that link gives me the store. I considered opening a case, but at the same time, I thought maybe others would have the same problem and we could post the fix if it is something simple. I will go ahead and open a ticket.

Were you able to figure this out? I have been having this problem for a while now. Multiple reboots, updates, different browsers, same problem. I have the same issue as you where the store is NOT defaulting to anything. (Selecting production doesn't do anything either.)

Thank you very much. I know sometimes (most of the time) these things don't really end up making money, and I (we) appreciate your dedication.

@bpwwer I have a question. From a quick look at the code (not knowing Python) it appears that the "yearly rainfall" is year to Date, correct? (As opposed to a rolling 12 months). If it is the latter, I need to figure something else out.

Very good call! Can’t believe I didn’t think of that.🤦‍♂️ That will totally solve that.

I implemented it with a few variables and a single problem. I just have to remember to update the "before this year" variable Jan 1st (or around there) to avoid having to back out math. It is all being sent over to Home Assistant, and I ordered a used fire tablet to show all the data I want to keep track of everything that is going on in the house.

Let me start with this, I agree its not free, it has costs. Your point is 100% valid. But accumulated rain is something that most weather systems have (Davis, WF, La Crosse, etc.). And Total rain is the only one on the list that is missing out of this NS. They do not provide cumulative UV data as an example. So I don't think it is slippery slope you are thinking it is. Having said that, I have officially given up my crusade on this topic. It isn't my call to make, and I don't want to end up pissing you off for something that we just simply have different points of view on. It isn't remotely worth it. You are the one that has to decide what is worth your time and what isn't, and what will make you money in the end. I am working on getting the data with a manual variable the has everything before this year and add that to YTD we already have, and I will just manually update it at the end of the year, and it will work. No big deal. I already started this last night, but I need to figure out how to get a program to add the NS data to a variable. I will toy with it when I have some more time. Maybe tonight, IDK.

Obviously we are going to have to agree to disagree and that’s okay. For some reason your suggestion to “invoice me” really rubbed me the wrong way. I think it’s the formality of it. I’m not sure. It’s funny. I was thinking this morning about PM’ing you and ask you if I flipped you some money if you would do it, but I guess that’s not going to be an option. anyway, if you read my last comment I already assumed you don’t have any interest in doing anything that isn’t of immediate automation value. And that’s your prerogative. I do understand that and I see your point. I really do. But please update the data model to the current tempest API so at least I can at least have accurate data to make watering decisions (which of course is exactly what you want in an integration like this.). We can all agree the NC data is often far more accurate than observed data. Want proof? The Rachio integration with WF only uses NC data. Having both would probably be best, but as you point out, it has costs. All of this is a good excuse to get back into scripting. I haven’t touched it since the VBS days. I guess it’s time to learn python. If I do end up writing it I will give you what I write. You can use it or not. That’s your call. I would just be a couple of lines in your existing subroutine.

I guess some people use data, and some people ONLY do automation. I do both. As for your comment that others are not asking for it, that is not true, and least not with Home Assistant if you want to go looking around, in fact they have whole systems designed to store sensor data for just this reason. with the EISY adding display and purposely marketing it for exactly what I am trying to do, I suspect there are (or will be) others in the same boat in the UD camp as well. Think about the power data they are working hard to improve. It is historical as well in the same way. I think there is more than just automation here. But I guess not everyone agrees with that. @DennisCthat is exactly what I am planning on doing for now. Hopefully Bob will change his mind, but I figure that isn't likely. I could probably add the code myself, it is just a few lines over what is already there to have it done correctly (he is already making an API call and then parsing the data in the exact same way for month and year. This one would just be a third one that sets sets the epochdate so some far back time, and do it a 3rd time. i may try to figure out how to edit the code on the EISY directly to do that. But I will need to wait until the updated data set is in so I don't have to do it twice as it is all going to change at that point.

Thank you. Looks like you are right. They must have updated it. I was using the swagger interface for my testing which is by default whatever the latest version is. Here is where is why all time rainfall is useful... If you are actually trying to display data, it is important. In my case I am using a display to do it. Frankly, why not just add whatever is realistically available? I am using Home Assistant to aggregate everything and display on a Fire Tablet (or something). I am now able to get the data from the NS into HA, so that's a big step forward. This is now the only thing that is missing for me to finish my project. Will be used by others? Maybe, maybe not, but it is fairly simple and should not hurt anything, and I would really appreciate it. If I can help in some way, I am happy to do so. I don't code much at all, but I have been in tech for 30 years, and work in IAM security.

I just spent some time in the code in the NS, it is using the wrong data (or at least I would argue that it is...) For the tempest (which is what I have), it is using 12 (Rain Accumulation (mm)) which it should be using 19 (NC Rain Accumulation (mm)). That would give you a far more accurate answer. My suggestion would be to have a config parameter to either use NC data (19) (as the App and everything else does) or use raw data (12) (which isn't very accurate for a sonic rain sensor). I am not a coder, but it also looks like added "all time" would not be that hard. It would mostly be adding it to the yearly and monthly subroutine. If I knew more about how this is all structured, I would try to do it myself.

yep. I even deleted and re-added the node server. Why would it have different data than the Weatherflow app?

Has anyone heard any movement on this? I have the same problem and can't get to some PG data because of it. I have to pull out the phone just to read data. It is not fun.