bpwwer

PG3 isn't very good about aborting the installation when something is wrong. In this case, PG3 tried to install the node on the IoP, failed and continued on as if it was successful. The only way to fix it was to remove the node server and re-install it once the credentials were correct. I've done some work for the next release of PG3 so it should handle this case better by aborting the install so you aren't left thinking it was successful when it really wasn't.

Don't know. the node server lists those as possible modes, but doesn't expose them. I don't know why.

In general, there are no known issues that prevent node servers from running or reporting data except for miss-configuration. Your configuration looked correct. The ETo might cause forecast data to not display or it may be because it doesn't have any data to calculate ETo yet. The second listing is normal for a new station as it tries to get precipitation data for the year, but you don't have any historical data yet. Neither would (or should) cause it to not have or not display data. Please attach or PM me the full log, ideally after you've changed the log level to debug and restarted the node server.

No. it was not removed. PG3, since version 3.0.57 has forced the udi_interface to update to the latest version when it starts.

I don't have any additional information beyond what's in the API docs. The node server simply calls the API and reports the values returned to the ISY. ETo isn't based on precipitation. It's a calculation of how much water evaporates from the soil.

I have no idea. Maybe having two accounts would work. The VUE API isn't a public API and what we're using has been reverse engineered so there could be issues.

Here's the documentation from WeatherBit: https://www.weatherbit.io/api/weather-forecast-16-day

With the current version of PG3, node servers in different stores are considered different node servers. To switch between stores you'd have delete the original and re-install from the other store. This also means that a license purchased for a node server in one store is NOT valid for the same node server in another store. So basically should not purchase a node server from the non-production store and probably not install from the non-production store unless the developer asks you to. This will change in a future release of PG3 where the same node server can be added to multiple stores and the license for one will then be value for the same node server in other stores.

Version 3.0.21 fixes the bug you were seeing. If you refresh the store you should see that version. Then restarting the node server will automatically install it.

Other people, have more than one station, not you. The separate forecast and local entries are for them. In your case, since you only have one station, it is the same station number that gets entered for both.

The configuration looks right. Looks like a bug in the node server is causing that error. Many people have more than one WeatherFlow station so the node server needs to know which station to pull data from and which station to get forecast data for. They don't have to be the same station.

PG3 doesn't really care about the name. The ISY may have some restrictions, but that would be the same for both PG3 and PG2. The address on the other hand has more restrictions and probably more likely to cause a failure. Can you PM me a log package?

Refresh the store, verify that version 2.0.1 of the node server shows up and restart the node server. Let me know if it works.

For the PG3 version you just need the API key.

I don't know. @Michel Kohanim?

I believe all of the purchase options work for non-production. So installing a trial version in a new slot should work and be a separate license from anything previously installed (trial or other) from the production store. You could even make the trial period longer or shorter and only have the trial option available.

I apologize for the lack of communication. This took us all by surprise. I believe it was a OS update that changed the Python version, not a change made specifically by UDI. Once we were aware of the issue, we were working just to understand the issue and come up with a fix. The latest upgrade should migrate all the Python based node servers to 3.9 in a controlled manner allowing them to install and run properly again.

Yes, it will charge you again. The current PG3 release treats every node server as unique, with a unique id. Thus even though it may be the same name in two different stores, they are treated as different node servers. The next release of PG3 will change this and allow the same node server ID to be used in different stores so you can purchase a non-production version and then use the same license to install the production version. But this change is still a ways off.

When the node server starts it queries AmbientWeather for information about your weather station(s). It appears that your network is not fully initialized and the query fails Query failed: HTTPSConnectionPool(host='api.ambientweather.net', port=443): Max retries exceeded with url: /v1/devices?applicationKey=7651edae3d7b44ee8ab5c3359b0c99469f30bf3d2a1d4f2c995b25d9c01a2cd3&apiKey=7407c4813e0f41f38be31752905a03377c3e1c41b3dd40b69f74fe4086fbebc8 (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8030f0970>: Failed to establish a new connection: [Errno 8] Name does not resolve')) It's failing because it can't resolve the name "api.ambientweather.net" to an IP address. It does re-try multiple times as you can see by the "Max retries exceeded" part of the message. There's nothing the node server can do to make name resolution work on your network while it's starting.

Yes, Python was updated. I believe the problem is that the new version of python conflicts with the old version so the old version gets removed. This is very bad for all the node servers written in python. Python uses the version number to determine where the third party libraries are installed. So what you're seeing is that the node servers start, but can't find any of the libraries they need. UDI is working on a fix.

I think that's probably about as good as it's going to get, at least for a while. I don't have time to try and reverse engineer the protocol differences in the controller you have right now. So I'm glad it is at least partially working as is.

The MagicHome API isn't documented so everything that works has been reverse engineered and there are still unknowns in the protocol. It looks like the flux_led project has figure out a lot more since the last time I looked at. I just added your device type to the list and set it up similar to another device. That could be completely wrong for your device. It is very possible that the animation speed settings are different for your device. For my devices, switching to another mode (like setting the on level to something) switches them out of effects mode. The devices I have support 3 modes, effects, white, and rgb. Setting the brightness level switches them to white mode. Node servers have no way to implement a color wheel control. Hue changes the color 0 = blue. Increasing will move the hue towards green, then red and finally back towards blue. The RGB level is the brightness level, this should effect all three (red, green, blue) leds equally. So rgb=100% and hue=17 should have been a shade of blue. But that assumes your devices work the same as the ones I have.

Version 1.0.3 should be in the store now, if you refresh the store you should see it. Then restarting the node server should automatically up date to version 1.0.3. Let me know if that work for the LED strip lights.

Thanks Kevin, No, don't buy another just to take it apart. I think that's enough info to add support for that type of device. I'll take a look at it soon.

By design. You could provide the bulb's manufacturer, model, and specs.