bpwwer

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

Are you on the latest IoX already? I believe this only works for version 5.5.9 so you should probably do an "Upgrade Packages" from the admin console, prior to trying to migrate.

Unless the node server is crashing, which it doesn't look like it is, the author may not have set default parameters so as @DennisC suggests, you may have to add them yourself.

If you set the node server log level to debug, it will output what it's getting from the SolarEdge server. Basically, from the above, what it gets from the server has no inverter data in it, but we don't know why. It's possible that you are exceeded some query limit. Seeing the actual return from the server may include details on why it has no data.

This should be fixed in the latest interface module for node servers. However, this isn't something that can be easily pushed out. Basically all node servers need to be modified to require the new module. For PG3 on Polisy's it only gets updated when a node server is installed that requires the new version of the interface module. For PG3x on eisy's, each node server install loads a separate copy of this module. So each would have to be modified and then re-installed. Over time, as node servers are modified, they'll get the updated version.

Pushed out yet another update. Hopefully I got it right this time. This is still version 3.1.24.

RYSE provides a retrofit automated shade solution for shades that are controlled by cords or beaded chains. A basic system consist of the shade controller itself (either corded or battery powered) and a bridge/hub to manage the shade controller. The RYSE-shades node server interfaces with the bridge/hub via your local network to receive status updates on the shade positions and allow the IoX to control the shade positions. To begin, install the RYSE-Shades node server from the Node Server store. Then go to the RYSE-Shades Node Server details page and select Configuration. To configure the RYSE-Shades node server, enter the IP address of the RYSE bridge/hub like so: Once you "Save Changes", the node server will connect to the bridge/hub and query it for all connected shades. It will then create a node in the IoX for each shade it finds. Restart the Admin Console (if running) and you will find nodes representing each shade. For example: You can then incorporate the shade into your automation programs.

Ok, a new version of 3.1.24 is back up and should have working dialog boxes again. "Upgrade Packages" should see it and update it.

All model dialog boxes are disabled. I don't know why this rebuild of the UI is like that. In the meantime, I've removed 3.1.24 and rolled it back to 3.1.23.

Version 3.1.24 of PG3x should be available now although it may take a few hours before your eisy checks for available upgrades.

Will be fixed in 3.1.24 that will be available as soon as I can get it out there.