Installed NodeLink v0.11.3 on a new RPI 5. Connects to ISY994 just fine when it starts. Everything works as it should. But after a while, anywhere from 20 minutes to a few hours, NodeLink appears to not be getting the XML responses from NodeLink posts.

 

You can see in the attached log when things go wrong but no errors at all.

 

When working, all the responses from the ISY to a post have the XML:
2025-06-27 21:43:15 - ISY Send: Variable caiwc1-ST added to queue (Val: -1, QS: 1)
2025-06-27 21:43:16 - ISY Receive: <?xml version="1.0" encoding="UTF-8"?><RestResponse succeeded="true"><status>200</status><reason code="0" /></RestResponse> (ns/2/nodes/n002_caiwc1/report/status/ST/-1/25)

When its stops working, it looks like this:
2025-06-27 21:43:31 - ISY Send: Variable caiwc1-ST added to queue (Val: 1, QS: 1)
2025-06-27 21:43:31 - ISY Receive:  (ns/2/nodes/n002_caiwc1/report/status/ST/1/25)

 

In this example, there's no logging between these two calls and no hint of an error anywhere. 

Everything is configured exactly the same way. In fact, I just copied the config.xml from the node directory on the old RPI to the new one. Everything worked immediately as expected but stops after a short while. 

Full log attached.
 

log.txt

The issue is the "Auto-Update ISY"(Auto-updates the ISY when a new NodeLink configuration is found)  option in the Devices tab. I read through the release notes and saw a bug related to that option as fixed and surmised the fix might have made it worse which it did. Works fine now after turning that check off. 

Previously, I tried various versions of .NET from from 5 to 9. Works the same from versions 6 to 9. Even though the release notes say it was moved to 5, the installer downloads 6. The config file for the dll still says 5. 

Basically, massive bit rot near the end of it's life a few years ago and not enough folks using it to even care since most everyone moved to Polisy and PG3.

Edited June 28Jun 28 by sorka

I used nodelink successfully for years. The design of it allowed there to be nodeserver type capability years before UDI offered it. It covered many devices, and supported them well.

The design of nodelink was based on .net  and UDI went in a different direction with polyglot; that created an architectural fork in the road. The developer moved on. Having said all of that, the quality of the software and the support offered was never in question

Bit rot is not accurate or fair.

5 hours ago, paulbates said:

I used nodelink successfully for years. The design of it allowed there to be nodeserver type capability years before UDI offered it. It covered many devices, and supported them well.

The design of nodelink was based on .net  and UDI went in a different direction with polyglot; that created an architectural fork in the road. The developer moved on. Having said all of that, the quality of the software and the support offered was never in question

Bit rot is not accurate or fair.

Of course it is. The existing installer doesn't work and has to be hand edited in ways that aren't documented because it still references files on a site that doesn't exist. 

At any rate, the issue returned, it just took longer. So at this point I'll either have to containerize my existing working installation or just keep using my Pi 3. If it's a timing issue, even containerizing it won't necessarily fix the problem.

1 hour ago, sorka said:

Of course it is. The existing installer doesn't work and has to be hand edited in ways that aren't documented because it still references files on a site that doesn't exist. 

At any rate, the issue returned, it just took longer. So at this point I'll either have to containerize my existing working installation or just keep using my Pi 3. If it's a timing issue, even containerizing it won't necessarily fix the problem.

Is this what you are searching for?  io_guy posted it earlier this year.

sudo curl -sSL http://reverbautomation.com/Files/install.sh | bash

 

Edited June 28Jun 28 by hart2hart

2 hours ago, hart2hart said:

Is this what you are searching for?  io_guy posted it earlier this year.

sudo curl -sSL http://reverbautomation.com/Files/install.sh | bash

 

Yes, but that install script links to files on the old site so it doesn't work unless you edit it. It has other issues too.

 

For kicks, I installed a fresh Debian container on my Synology, installed dotnet and a few required dependencies and then copied over the v0.11.3 NodeLink.dll and config files. Same issue there after varying amounts of time.

 

Interestingly, I had a very old container that has v0.9.36, the last version before moving to .NET which fired right up and works fine. 

 

I think the last ditch if I want to continue running the latest that works, which is v0.10.6, before the switch to .NET6, is to containerize it in with an older 32 bit debian and copy the current 3.1.7 .NET and files over. Not sure if I'm going to do that on the RPI or the Synology. I originally moved from the Synology years ago because of the power usage, but I'm past that now as I rely on the Synology to host media and file sharing services that need to be up 24/7.

Edited June 28Jun 28 by sorka

Io_guy was always great at helping others and supporting the XxxLink programs. I still use GCLink as my interface for IR commands to eISY. If you PM him, he’ll likely respond and help.

1 hour ago, hart2hart said:

Io_guy was always great at helping others and supporting the XxxLink programs. I still use GCLink as my interface for IR commands to eISY. If you PM him, he’ll likely respond and help.

Agreed. And my bit rot comment isn't meant to be denigrating or insulting. It's just reality that this plugin is very old and not supported any more. The main reason I still use it is because PG2 never worked with EnvisaLink/DSC as well as the original NodeLink and nobody ever added a node server for CAI in PG2. It's amazing how much stuff NodeLink worked with.

The one thing that I do miss not being able to run the latest v0.11 is the improved Rainmachine support. I have old Rainmachine sprinkler controller which I really like. That  hasn't kept me from writing my own integrations with the API, but having it working directly with ISY without any additional work would have been nice.

So it didn't take long. I created a Dockerfile that installs 3.1 and the dependencies along with NodeLink.dll and the config files. Built it for the synology and then created a container for it and launched it. Took just a few minutes.

Did the same on the RPI 5 using the same file. Using the last version of debian that supports 3.1.

 

Dockerfile attached in case anyone wants to use it. NodeLink starts as soon as the container is launched. The only downside is if MS removes availability of 3.1 in the future. After that, the only option to distribute this to the public would be to prebuild images for each platform that 3.1 is built for since the .net tar.gz files cannot be distributed publically unless they're part of existing software.

 

# Use Debian 10 (Buster) as base
FROM debian:buster

# Install dependencies for .NET Core 3.1
RUN apt-get update && apt-get install -y \
    curl \
    libicu63 \
    libssl1.1 \
    libkrb5-3 \
    zlib1g \
    ca-certificates

# Install .NET Core 3.1 Runtime
RUN curl -SL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh \
    && chmod +x dotnet-install.sh \
    && ./dotnet-install.sh --channel 3.1 --runtime dotnet --install-dir /usr/share/dotnet \
    && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet \
    && rm dotnet-install.sh

# Set working directory
WORKDIR /app

# Optional: copy your DLL into the image
COPY NodeLink.dll .
COPY config.xml .
COPY NodeLink.runtimeconfig.json .
# Default command (can be overridden)
CMD ["dotnet", "/app/NodeLink.dll"]

 

Dockerfile