Jump to content

Recommended Posts

Posted

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.

  • Like 1
Posted (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 by paulbates
Posted

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. 

Posted

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.

Posted

This version is way faster to start.

Of my devices:

  1. Venstar -- appears to connect and populate ISY data as intended
  2. WeatherFlow -- appears to connect and populate ISY data as intended
  3. Additional ISY Data -- appears to connect and populate the ISY as intended
  4. Relay Server -- appears to connect as intended
  5. 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.

Posted
14 minutes ago, Bumbershoot said:
  1. 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...

Posted

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.

Posted (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 by TJF1960
Posted
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.

Posted
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

 

Posted
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

 

Posted

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.

Posted

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

Posted
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.

Posted

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.

Posted
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.

  • Like 1
Posted
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?

Posted

Worked pretty well.  I converted the startup to use the systemd scripts instead of rc.local and all was good!  Thanks for the update.

Posted

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.

  • Like 1
Posted

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

Posted

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
 

Posted
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.

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...