bpwwer

Unfortunately, I am not the developer of that code. I can only make changes to the PG3(x) code base, not the IoX firmware or other UDI components on the Polisy/eisy. The IoX firmware needs changes for it to be able to send commands to PG3(x). If that was done, I'd be more than willing to update PG3(x) to accept those command for node server control. And I agree, we should be able to control node servers from IoX, but not my call.

Thanks @Ross I appreciate the comments and thoughts. I understand the desire to see every possible piece of data, but there has to be limits. If we're going to add rain accumulation since the station came on-line shouldn't we then do that for everything? Why not accumulated UV ratings since the station came on line. Or accumulated temperatures, dewpoint, humidity, wind, etc. All of these are meaningless numbers. I could just have the node server generate an ever increasing random number and it would have just as much meaning. I also understand the point that you may not have a use for data until you see it. And if we were talking about a specific sensor reading, I'd agree. Real-time sensor data has meaning. The example of soil temp has meaning, summing up all the soil temp readings since your station came on line does not. I've also been trying to get across the point that making changes/additions to node servers is not "free". Even what can seem like a simple change can have unintended side effects. Adding additional code means more testing and more effort over the life of the product. So if you're going to ask for a change, you should be able to articulate why that change is important.

I'm sorry that offering to provide a cost estimate rubbed you the wrong way. But I create and sell node servers and part of my business and I have to make decisions based on how that will effect my business. If you were asking for something that I though would enhance the product I'd likely just do it, but despite me asking with every reply, you still have not shown how this would enhance my node server. It's not a question of how hard or easy it is to do or even a question of interest. I certainly don't think I know best how data can be used or not. I can be convinced. Provide me with a real-world example of how reporting rain since system installation can be used to do something you can't do without it. That's all I've been asking for and I don't think that's unreasonable. There's no question that the NC data is valuable. I thought that's what was being returned in the server queries and didn't realize that they had added new fields for that until I looked it up after you asked about it. WeatherFlow doesn't notify me of changes to the their API. Updating that is on my list and is fairly high on the list.

You still have not described how you will use the data. The data is only valuable if it can be used in some way. Displaying it so you can look at it and say "Wow, my system has recorded 4956 inches of rain since I started collecting data" isn't making use of the data. The reason we collect data is to drive decisions with that data. In general, for home automation, that means looking at real-time data and making decisions in real-time. But that doesn't exclude making use of historic data. And I'll say it again, adding features is not free. Since I can't see any way adding this would increase sales, I can work up an invoice on how much it will cost to add this for you if you'd like.

This is the problem. IoX doesn't have any way to issue a command to PG3. There's no API in IoX that lets it send commands to PG3. You can send commands to node servers, but that won't work because you're trying to restart the node server, it probably isn't alive to get the command. There's also security issues to think about. You can issue a restart manually because you're logged in and authorized to do that.

I understand the desire to have a method to recover with things go bad in node servers. I made some proposals for this before PG3 was developed, but other things took priority. Because of the way things are designed, the only practical way to do this is to have node server status built into the IoX firmware so that that IoX can detect when a node server needs to be restarted and code added to IoX to send commands to PG3 to restart node servers. We've tried to work-around this on the node server/PG3 side by allowing node servers to have a "status" value to indicate it's health, but that is really only able to detect if PG3 loses connection to the node server, not really if the node server is operating correctly. But this is only half the solution. We still have no way for IoX to signal PG3 that a node server should be restarted, there's just no way to do that with the current IoX or PG3.

PG3x version 3.1.23 was extra chatty as we used that to do some initial testing for PG3x remote access. That has been removed in the latest version 3.1.24 of PG3x.

I still don't understand why displaying this data is important other than because you want to see it. The node server (well all node servers) are used to get data into the ISY/IoX home automation controller. Historical data, while interesting to view, isn't typically useful to enhance the control functions. rainfall year to date could be of some use in controlling irrigation, but a three year total, not so much. Because it's not free. It takes time to add features and more features means more complexity in the software and more complexity means more effort to maintain the software. I've been providing a WeatherFlow module for a couple of different Home Automation systems for over 5 years and no one has asked for this before. So I'm pretty confident that adding this will not increase sales at all. So it really comes down to a business decision. Is it worth my time to add this feature? Or do I use that time for something else that will generate more income? While it may seem simple, it's not. WeatherFlow doesn't make the data available via a database interface. If we could just do something like "select * sum(rain);" it would be simple. But the API can only query over specific time frames, "for all time isn't specific" That means making queries using earlier and earlier time frames until it returns an error and accumulating all the records returned with each query. Because the ISY/IoX isn't designed to maintain historical data, this process would happen every time the node server starts. How much additional time it adds to the startup will depend on how long the station has been in operation, increasing over time. Over time, because you're asking for all of station records, WeatherFlow may have to put limits on the queries. So no, it's not simple, and there's a possibility of negatively impacting the node server performance.

The node server is using the official local API from WeatherFlow https://weatherflow.github.io/Tempest/api/udp/v171/ According to that, there isn't a field 19. Looks like they changed the remote API at some point to split the NC rain out and added new fields. The node server is using the same code to process both local and remote as they're identical up through field 17. So it's not as simple as just switching to field 19 as that will break the local handling. I'll add support of the NC fields with remote to the todo list. I didn't say it would be hard to add rain for all time, I just do see how that could be at all useful in a home automation setting. Adding features that have no real value comes at a cost. It makes the code more complex and has to be maintained. I'm not charging enough for the node server for me to want to do that. The ROI for me, just isn't there.

Upgrade PG3x to 3.1.24 and you will be able to delete node servers again. It was a bug in version 3.1.23. There isn't any way to delete node servers via ssh.

When/if it happens again, capture the node server log and send it to the Tesla node server author.

PG3x uses the UDX component to authenticate. A 401 means that UDX specifically returned that error to PG3x to indicate that the username/password is not correct. I don't really know how UDX does that check, it may actually use IoX since it is supposed to be the same username/password used to log into IoX via the admin console. So one possibility is that IoX isn't running or is in a state where it doesn't respond properly. Can you use the admin console to log into IoX at this point?

If it's reproducible, it would be good to submit a support ticket and let support take a look at your system to try and understand why that is happening. There should be no difference between rebooting and power cycling the eisy. However, I've experienced cases where reboot from the AC simply doesn't work. I.E. it doesn't actually cause the system to reboot.

Not the node server, pg3x needs to updated and you do that via the AC. The current version of pg3x is 3.1.24.

Great comments @MrBill I agree that options are always good, but options aren't free. It takes resources to implement them in the code and more resources to maintain multiple options. I didn't want to make the poll to complicated and appreciate the comments like yours to provide context to the results.

I guess you'll need to define what you mean by "Hacking". I specifically used the term "reverse engineering" because that term is better defined. It specifically means that you don't have access to the code and are simply using examining how the companies components interact with each other and use that information to replication the interactions. "reverse engineering" is legal, at least in the U.S. I would define "hacking" as using various methods to gain access to the actual code that was written and using that code in an implementation. I'm not aware of any node servers that do that. For MyQ, you'd have to ask @Goose66 how he figured out the API, but I'd guess it wasn't by having access to the mobile application code or the MyQ device firmware.

Being aware of the pros and cons of both ways, there's not a clear "single solution" that works for everyone. But it is clear that communication is key to however it is handled. Also, when things go bad, it doesn't really matter if it was a pushed update or a pulled update. It just needs to be fixed as quickly as possible.

@TRI0N it's good that you're investigating to make sure you aren't taking risks you can't afford. So you should also be aware that many node servers are using reverse engineered API's, The MyQ is just a little more transparent about it. You may have to do a bit of digging to find out if the node server is using something you're comfortable with or not. And even then, it may not be 100% black and white. For example, Emporia doesn't make the API to get data from their devices public, but they have worked with the developer that reverse engineered it and have said it's ok as long as folks don't abuse the servers.

Trying to bring some of the deep, dark secrets of home automation into the light? Many companies are unwilling to publish/support a public API to their hardware and only provide a mobile application to control said hardware. My guess, is that this is all cost driven. The cost to maintain documentation and support for a public API for very little gain in sales isn't worth it. So to use that hardware with home automation, the API needs to be reverse engineered. In most cases, those that are doing this, aren't causing enough issues for the companies to actively block the use. So in general it works. However, should the company decide to update/change the API, those using a reverse engineered solution are blocked until the work can be done to handle the update/change. It's a risk we take. My understanding is that @Goose66 is trying to mitigate that risk somewhat by charging a fee to support the efforts to deal with updates and changes to the API. The legality of this is somewhat a grey area. In the US reverse-engineering is considered fair use under federal copyright law. Furthermore, the DMCA (Digital Millennium Copyright Act) contains an explicit provision allowing reverse-engineering for purposes of interoperability. I believe node servers fall under the umbrella of interoperability. We're not trying to steal anything from MyQ, just trying to use legally purchased equipment in a way the manufacturer isn't directly supporting.

This is a poll to get a general idea on how customers would like to see updates handled. With the eisy, the various components UDI creates are becoming more interdependent. This means that updating one, can effect others. Because of this, the more reliable way to handle a lot of updates is to simply reboot the eisy to make sure everything starts correctly and is in sync. Updates typically add new features but may also only be bug fixes. In the past, it's been mostly left up to the user to "pull" the update, however, we are seeing a lot cases where user's are running older versions of components and then reporting bugs that have already been fixed in newer versions. So there are pros and cons to "pushed" vs. "pulled" updates. What's your opinion?

It's a fine line. So many folks want everything to just work and happen automagiclly but we can only do that if we have control and use "cloud" based systems to make it happen. It is still a goal to have things work even if access to the Internet is removed, but more and more, the enabling of features requires Internet access. We're slowly trying to integrate the various components, but that also means that they are becoming a lot more interdependent. PG3x depends on IoX to function properly both PG3x and IoX depend on UDX to function. There are OS services that all three depend on. So now when we try to update one component, it can impact all and the safest, more reliable way to ensure they are all working together is to reboot the eisy. Back when it was just the ISY, it was just one component, but that was still rebooted when the firmware was updated. The main difference was that user's had to initiate the update, it was never pushed. Maybe that's what should have happened here too, instead of trying the push the update, it should have been user initiated. I don't know.

That would be a question for WeatherFlow. I would think that their app gets the data the same way the node server does, but I have no way to confirm that. When I first created the node server it matched what was reported on the app, but the app has changed significantly since then.

Did you restart the node server after switching? The node server isn't doing anything but reporting the data it gets from the server.

The behavior somewhat depends on how you've configured the node server. When the node server starts, it queries the servers for the historical rain. I don't believe they provide an option to get total rain since the station came on line. It is probably possible to generate queries to get that but I'm struggling to understand how that information would be valuable for automation. If you've configured the node server to use local values from the hub, then historical rain ends up being what was queried initially plus what the hub reports locally. The whole point of using the local data is to not have to rely on the internet connection for the data. To have most data be local but rain be queried from the server breaks that design goal. If you've configured the node server to use remote values from the server, then you're getting NC rain data from the servers and the values should be very close, if not exactly the same as what the app reports. Unfortunately, WeatherFlow has decided to use server side processing to modify the values generated by the local sensors rather than fix the firmware to make the local sensors report correct data. Which is why you have the choice, you can use the local sensor data and deal with any inaccuracies or use the server data and get the "corrected" data. Your choice.

If PG3 is reporting the node server's status as "Failed", that means that it has stopped communicating with PG3.