io_guy Posted September 29, 2019 Posted September 29, 2019 So with the issues with mono 6 and the fact that .NET Framework will be replaced with .NET Core in the future (just called .NET 5), I've moved NodeLink over to the newly released .NET Core 3. NodeLink will not auto update to this version since it's a big change. If there are any brave testers with a Raspberry Pi out there, you could try the new script: sudo curl -sSL http://automationshack.com/Files/install-core.sh | bash This will download .NET Core 3 Runtime and the new NodeLink. It will also switch your startup script. You current config will stay, as will the NodeLink.exe as the dotnet runtime uses a NodeLink.dll file instead. .NET Core has many performance improvements over mono and a smaller install footprint. 1 Quote
macjeff Posted September 29, 2019 Posted September 29, 2019 I use MacOS X and running Mono 6. So far no issues on my end with v 6.4. I would be glad to test if you are interested in a tester on MacOS X. Jeff Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 Sure I just don't have a script for it. The files can be downloaded here:http://automationshack.com/Files/NodeLink.zip Just extract it into your NodeLink directory, it'll use your existing config file. You'll need to install the .NET Core 3 Runtime, they have binaries or an installer for OSX:https://dotnet.microsoft.com/download/dotnet-core/3.0 Then to run it's "dotnet NodeLink.dll". Quote
paulbates Posted September 29, 2019 Posted September 29, 2019 (edited) I have a backup / dev b+ I can try it on.its already set up with existing nodelink.. It will be a.good test for the larger audience here Paul Edited September 29, 2019 by paulbates Quote
dwengrovitz Posted September 29, 2019 Posted September 29, 2019 Wow ... your timing could not have been better. I was literally in the process of re-building the NodeLink setup on my Pi 3 b+ late last night when I saw your notice so I switched plans. Installation on Debian 10.1 went fine, and the interface to my DSC panel and Honeywell thermostats seem to be working. The NodeLink web interface on the mono version would frequently show periodic errors for me, like timeouts or problems with the stats responding, but so far this morning the panel is error free. I am also running Polyglot on the same Pi. Will let you know if anything crops up but so far all is well. Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 Thanks for the feedback. In theory .NET Core should run better and have less chance of breaking between revisions. There are performance improvements they made and all versions are written by the same core team (and it's MS's plan going forward for replacing Framework). I did remove serial port support in this version. Serial port support is an add-on which is platform specific so I would have needed to distribute separate files for every OS. I'm sticking with the core runtime for simplicity. This affects the CallerID module and if anyone was using serial port for GEM. The easy solution here (I use both) was to apt-install ser2net on the Pi, which handles the serial port work and exposes a TCP socket for each comm port. Quote
Bumbershoot Posted September 29, 2019 Posted September 29, 2019 This version is way faster to start. Of my devices: Venstar -- appears to connect and populate ISY data as intended WeatherFlow -- appears to connect and populate ISY data as intended Additional ISY Data -- appears to connect and populate the ISY as intended Relay Server -- appears to connect as intended RainMachine -- NodeLink does not connect to RainMachine -- RainMachine IP address and password are correct, and "Use HTTPS" status is correct (unchecked). RainMachine is up and running at the specified IP address, on the specified non-secure port (8081), with specified password. Other than the RainMachine, all appears to be good. Quote
Bumbershoot Posted September 29, 2019 Posted September 29, 2019 14 minutes ago, Bumbershoot said: RainMachine -- NodeLink does not connect to RainMachine -- RainMachine IP address and password are correct, and "Use HTTPS" status is correct (unchecked). RainMachine is up and running at the specified IP address, on the specified non-secure port (8081), with specified password. Please disregard -- RainMachine is now working as intended on the new NodeLink. Thanks, and sorry for the problem. Network issue here... Quote
Bumbershoot Posted September 29, 2019 Posted September 29, 2019 Now that all my devices are working, I get this error in NodeLink related to my RainMachine when the "Enable Weather Node" checkbox is checked: 22019-09-29 07:42:00 - ISY NodeLink Server v0.10.0 started 2019-09-29 07:42:00 - OS: Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux 2019-09-29 07:42:00 - Web config server started (http://192.168.1.5:8090) 2019-09-29 07:42:01 - ISY resolved to 192.168.1.20 (5.0.15A) 2019-09-29 07:42:01 - ISY Node Server config detected (profile 2) 2019-09-29 07:42:04 - Relay Server: Started on port 2405 2019-09-29 07:42:06 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:42:37 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:43:07 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:43:38 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] I don't have a rain sensor attached to my RainMachine, so I suspect this should be normal/expected? This error goes away when the checkbox is unchecked. Quote
TJF1960 Posted September 29, 2019 Posted September 29, 2019 (edited) Hi io_guy, Two thumbs up! Out of all the upgrades to all the other apps and programs I have ever installed this was the easiest and with no issues what so ever. It worked right out of the gate! You have made it so easy with your script. Everything populates quickly and with no errors. Thank You!!! Two questions. First I moved the "node" file from home>pi to another folder I have all other data in for ease of copying for backups. Do you see any issue with moving the folder to a new location? Other than having to change the location in rc.local? Second, I had old Nodelink started as a service and would like to do the same with the new version. With mono ExecStart=/usr/bin/mono / was used in the service to start nodelink, what would I need to change the file locations to for dotnet? Thanks for all of you work and help! Tim Edited September 29, 2019 by TJF1960 Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 2 hours ago, Bumbershoot said: Now that all my devices are working, I get this error in NodeLink related to my RainMachine when the "Enable Weather Node" checkbox is checked: 22019-09-29 07:42:00 - ISY NodeLink Server v0.10.0 started 2019-09-29 07:42:00 - OS: Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux 2019-09-29 07:42:00 - Web config server started (http://192.168.1.5:8090) 2019-09-29 07:42:01 - ISY resolved to 192.168.1.20 (5.0.15A) 2019-09-29 07:42:01 - ISY Node Server config detected (profile 2) 2019-09-29 07:42:04 - Relay Server: Started on port 2405 2019-09-29 07:42:06 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:42:37 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:43:07 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] 2019-09-29 07:43:38 - RainMachine: Poll Error - ValueType 'System.Double' cannot be null. [rain1] I don't have a rain sensor attached to my RainMachine, so I suspect this should be normal/expected? This error goes away when the checkbox is unchecked. No rain sensor here either but it works fine. Your system must not be returning values for the qpf info. I'll add some error handling. Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 1 hour ago, TJF1960 said: Hi io_guy, Two thumbs up! Out of all the upgrades to all the other apps and programs I have ever installed this was the easiest and with no issues what so ever. It worked right out of the gate! You have made it so easy with your script. Everything populates quickly and with no errors. Thank You!!! Two questions. First I moved the "node" file from home>pi to another folder I have all other data in for ease of copying for backups. Do you see any issue with moving the folder to a new location? Other than having to change the location in rc.local? Second, I had old Nodelink started as a service and would like to do the same with the new version. With mono ExecStart=/usr/bin/mono / was used in the service to start nodelink, what would I need to change the file locations to for dotnet? Thanks for all of you work and help! Tim No issue changing location, just need to charge startup script(s) as you mentioned. The install script extracts dotnet into the folder /home/pi/dotnet. It also creates a symbolic link to /sbin. So, you could either use /sbin/dotnet or /home/pi/dotnet/dotnet Quote
Bumbershoot Posted September 29, 2019 Posted September 29, 2019 4 hours ago, io_guy said: No issue changing location, just need to charge startup script(s) as you mentioned. The install script extracts dotnet into the folder /home/pi/dotnet. It also creates a symbolic link to /sbin. So, you could either use /sbin/dotnet or /home/pi/dotnet/dotnet Just an FYI: Interestingly, the config file in '/home/pi/node' was created with 'root' ownership/permissions. My usual practice is to keep things in user directories owned by that user, so I changed the ownership of '/home/pi/node/config.xlm' to user 'pi' to give my '/bin/systemctl' control file ('/etc/systemd/system/nodelink.service') permission to run. I could have also just eliminated the 'User=pi' line. [UNIT] Description=NodeLink Server Documentation=http://automationshack.com/nodelink.html Requires=network-online.target After=network-online.target [Service] Type=simple ExecStartPre=/bin/sleep 10 ExecStart=/home/pi/dotnet/dotnet /home/pi/node/NodeLink.dll Restart=always User=pi [Install] WantedBy=multi-user.target Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 The issue is with the rc.local since it starts NodeLink as root, it'll create config.xml as root. Suppose I could change this to su pi -c 'dotnet /home/pi/node/NodeLink.dll &' Or I could drop everything to pi so that first-time install runners would start NodeLink as pi, hence ownership of the xml would stay as pi. Quote
paulbates Posted September 29, 2019 Posted September 29, 2019 Nodelink working here as well, updated via the script. When it came up, config.xml hadn't been copied over, but probably due to me having my config.xml in a directory I had used since the xxxxlink days...it was easy to diagnose/fix. Paul Quote
Bumbershoot Posted September 29, 2019 Posted September 29, 2019 4 minutes ago, io_guy said: The issue is with the rc.local since it starts NodeLink as root, it'll create config.xml as root. Suppose I could change this to su pi -c 'dotnet /home/pi/node/NodeLink.dll &' Or I could drop everything to pi so that first-time install runners would start NodeLink as pi, hence ownership of the xml would stay as pi. The symlink to '/sbin' will have to be owned by 'root', won't it? Back in my sysadmin days, I did everything I could to keep other admins from using the 'root' account when it wasn't necessary. It probably doesn't matter that much on your average RPi, but maybe for consistency (Polyglot installs under the user account, not the 'root' account) the user account might be preferable? Do you know if 'dotnet' and it's supporting files will be included in the standard 'apt' repositories, going forward? I'm imagining that they will, which may make it somewhat more difficult for users to update the file(s) if they're located in a user directory. Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 I updated the script to create everything as pi (with the exception of the symlink which has to be root). I chown the xml so that it's to pi.pi in case an old install created it as root. I've left the rc.local as root - a user can switch to pi if they want but I'm really not too concerned about running as root. I suspect that once dotnet 3.1 comes around (which is LTS) end of 2019 that distros will make packages for it. I really don't mind the binary lump though since it requires no compile and gives full flexibility on the install script. Quote
io_guy Posted September 29, 2019 Author Posted September 29, 2019 27 minutes ago, paulbates said: Nodelink working here as well, updated via the script. When it came up, config.xml hadn't been copied over, but probably due to me having my config.xml in a directory I had used since the xxxxlink days...it was easy to diagnose/fix. Paul Glad to hear. Once we get a few more days runtime on it I'll release this officially. 1 Quote
Bumbershoot Posted September 29, 2019 Posted September 29, 2019 12 minutes ago, io_guy said: I updated the script to create everything as pi (with the exception of the symlink which has to be root). I chown the xml so that it's to pi.pi in case an old install created it as root. I've left the rc.local as root - a user can switch to pi if they want but I'm really not too concerned about running as root. I suspect that once dotnet 3.1 comes around (which is LTS) end of 2019 that distros will make packages for it. I really don't mind the binary lump though since it requires no compile and gives full flexibility on the install script. This seems all good. Thanks again for all your excellent work! Looking foreward, I read the .NET Core 3.x is available on FreeBSD. If so, is it possible that NodeLink will have an install script on the Polisy? Quote
io_guy Posted September 30, 2019 Author Posted September 30, 2019 Yep, that was always the plan. It needs to be compiled for BSD but shouldn't be difficult. 2 1 Quote
glarsen Posted October 3, 2019 Posted October 3, 2019 Worked pretty well. I converted the startup to use the systemd scripts instead of rc.local and all was good! Thanks for the update. Quote
io_guy Posted October 4, 2019 Author Posted October 4, 2019 Glad to hear there's no issues so far. I've squashed a number of bugs over the last few days, amazing how many differences/quirks there are between Framework and Core. Anyways I'll convert everything over officially in the next week or so. I have it running on Docker as well so that now covers Windows, Linux, Linux Docker and OSX. Did discover that my Hue Emulator is broken, but it looks like it was pre-conversion that it stopped working. Need to dig into that one deeper. 1 Quote
paulbates Posted October 4, 2019 Posted October 4, 2019 Thanks for doing this io_guy. I appreciate that Mono has been there in the past, but running on the actual MS stack will be better for me. Paul Quote
eyaniv Posted October 10, 2019 Posted October 10, 2019 Thanks io_guy. trying this, I get the following error: A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/eran/nodelink/dotnet/'. Failed to run as a self-contained app. If this should be a framework-dependent app, add the /home/eran/nodelink/dotnet/NodeLink.runtimeconfig.json file specifying the appropriate framework. Eran Quote
eyaniv Posted October 10, 2019 Posted October 10, 2019 8 hours ago, eyaniv said: Thanks io_guy. trying this, I get the following error: A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/home/eran/nodelink/dotnet/'. Failed to run as a self-contained app. If this should be a framework-dependent app, add the /home/eran/nodelink/dotnet/NodeLink.runtimeconfig.json file specifying the appropriate framework. Eran Thanks glarsen for the pointer! according to dotnet publish process, the output should be the following. I'm missing from the downloaded zip the runtimeconfig, and any dependencies needed. my environment is Debian 9. Thanks Eran Quote dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets: Intermediate Language (IL) code in an assembly with a dll extension. .deps.json file that includes all of the dependencies of the project. .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type). The application's dependencies, which are copied from the NuGet cache into the output folder. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.