bpwwer

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.

I understand, I really do. I just don't like adding band-aid features as those "temporary" fixes tend to turn into long-term solutions that have to be maintained and real problems are left unresolved. I can only speak for myself here, but I only use a small number of the node servers I've actually written. So unless the people using them speak up about problems, I won't know the problems exist and I won't fix them. In my opinion, it's worse to have broken node servers out there because they'll frustrate anyone who installs them and that taints the whole experience. @residualimages you're experiencing this now and my goal is prevent this from happening to others. Which is why I say you can always contact me. I'll try to help resolve node server issues. I may not always be able to, but I'll try.

I don't understand what you're asking. You can re-install today. Go to the store, select the node server, click on the "Install" button and you have the option to re-install to the same slot. That installs the latest version but doesn't wipe your existing configuration or nodes. If you "Delete" and then "Install", it wipes everything and installs fresh. So today there are 3 options: 1) automatic update (which may or may not work) 2) re-install 3) delete and install

Auto updating has been problematic for a while now. It started having issues when I added a the ability for node server developers to release multiple versions of the same node server. Previous to that, PG3 didn't need to know what you had purchased, you had simply purchased node server X and if there was a new version of node server X, it could update to that. Now there could be node sever X standard edition and node server X professional edition so PG3 has to know which one you purchased to know if it can update what you have. In some cases it's easy for PG3 to determine what you have installed and update, but in many cases now, what was installed doesn't have the information PG3 needs to know what it should update. In this case you can manually update using the "re-install" option. The "re-install" option does the same thing as a update, but you have to tell PG3 what purchase option to use when updating. "re-install" doesn't delete existing nodes or delete existing configuration so you won't have redo configuration. About a month ago I made a change that broke version detection for some (many) node servers. This also impacts the auto update as it compares the running node server with no version to the version in the store and says you need to update. It can't tell that the version you're running is the latest because of the missing version info. Unfortunately, the fix can't be pushed out globally and may require the individual node server to be modified by the author to require the fix and then be re-installed.

Restarting node servers or restarting PG3 multiple times a day is not normal or even close to normal behavior. Trying to fix it by automating the restarts doesn't do anything to resolve the underlying problem. I understand that not all node server authors are responsive and there are currently quite a few that are basically unsupported at this time. But the first step should always be to try and contact the author for help. If the author is unresponsive or says they can no longer help, PM me and let me know. I'll do my best to help. Also, and this is more of a general comment, when looking for help on a node server, the log file is critical. When one isn't working as it should there's a good chance that the log file will include the reason and simply reviewing it lead to a resolution. Ideally, capturing the log file with the level set to debug is best.

You'll have to submit a support ticket. https://www.universal-devices.com/my-tickets