Forked Node-Red Package Fails upon minor change (1 to 2)

[stokes776]

Hello,

EDIT: I have posted on the issues page of the original repo, on a thread where someone was asking for a similar feature years ago, but there has been no response.

Im using a package that works exactly the way I want.

node-red-contrib-oled

Slight problem is that it hard codes its i2c-bus to a value of 1.
I have a new hardware board, a Beaglebone Green, and its i2cBus is 2.

As an initial test, I modified the oled.js on my one device, manually, and changed the 1 to a 2, restarted NodeRed and vwala it worked!

I figured I could just fork the library, make the change in the new fork (or better yet paramaterize it) and then in my build, just call MY new fork for the npm install.

Alas this doesnt work. My new fork loads, it shows in node-red palete manager, but it wont write to the new value.

Is there something about a fork, or maybe loading NPM from a github repo that breaks things that I am not aware of? I figured this would be an extremely simple thing, changing a 1 to a 2.

[Colin]

Did you uninstall the original and then install yours?

How did you install yours?

Did you restart node red and refresh the browser?

Is that the only change you made to the code?

Have a look in the node's folder in node_modules and see if your choice is there.

[stokes776]

Thank you for the reply Colin

Did you uninstall the original and then install yours?
Yes, I am using Balena to compile an container, with node-red and the npm packages.
When it does a build, its fresh each time.
So the exact answer, is, in my Dockerfile.template I call...

How did you install yours?
Using 'npm install -g --unsafe-perm stokes776/node-red-contrib-oled

Did you restart node red and refresh the browser?
Yes, when the device (a Beaglebone Green) sees the new 'release' in Balena, it downloads the new release, stops the current image, and swaps over to the new one and fires it up.

Is that the only change you made to the code?
Initially yes, but after it did not work, I also tried modifying the package.json to increment the version number. I did another release, and in the Node-Red Palete manager I saw it went up to 1.0.

GitHub - stokes776/node-red-contrib-oled: Node-Red node to talk to OLED...

Here are my two commits to my fork:

Then when that didnt work, I wanted to make sure I was really getting MY version, and so I updated the version:

Have a look in the node's folder in node_modules and see if your choice is there.
I can SSH into the container with balena, and I navigate down to

cd /usr/local/lib/node_modules/node-red-contrib-oled
and then nano oled.js, and it matches up with what I expect to be there.

I am currently back in a mode where I tested the original repo, and after I manually edit the file to 2 and restart, it works again.
If I push my repo down, I get setCursor errors.
I feel like I am going insane here. Is there something with my repository not being a true NPM repository yet? I was under the assumption that npm installing from github repo was OK and acted the same.

[Colin]

@stokes776

I manually edit the file to 2 and restart, it works again.

Is that the same file that you looked in when you installed your fork?

You haven't said what happens when you run your fork. Unless I missed it.

[stokes776]

Sorry, you are right, I glazed over that in a non-helpful way.

When I run my fork, node-red fires up, and the nodes are there in the Palete. In Palete manager they are there.

I have an inject that every 15 seconds or so tries to write to the OLED (time, temp, some stats of the device), and some manual nodes to turn it on/off.

When I use my fork, I get errors in my OLED flows:

If I nano the file in balena, the file has the value I want, same as when I do the original package and manually edit.

[Colin]

What is that 'module not found' at the top of the image?

[stokes776]

That is the node-red-contrib-balena module. I don't know why it doesnt load exactly:

But it is present in the dash. I use it for some logic if the device looses connectivity or under certain situations to call for a container restart.

[Colin]

If you look at the oled node's page on the flows site you will see that it was last updated seven months ago. However, if you look at its page on github you can see that there have been numerous updates since then, that have not been released to npm.
Unfortunately there does not appear to be a release label in github for 1.0.5, which means that you cannot easily branch at that point and make your changes there.

If you install from github from the latest source of HendrikRoth/node-red-contrib-oled does it work?

[stokes776]

Thats a very good point, maybe the github version I am forking from is flawed somehow.
I will check that and see, thank you again for the clarity. Ill update with my results.

[stokes776]

Thank you @Colin , that led me down the right path.

On my windows machine, new directory, npm install node-red-contrib-oled.
Looked into node_modules, and looked at the oled.js.

I compared that oled.js to the oled.js that I got from the github repo.
I used WinMerge to compare the files.
NPM on the left, github on the right
There was a difference!

Looks like the github version changed how they parsed the 'address' of the i2c device (not the bus, rather, but the address).

In my code my device was 3c, so it was failing or being adjusted not how I expected it in the existing devices, which were running the NPM version.

This was, on my new fork, causing my new fork to fail to function properly, because my address was wrong. From the UI, it didnt throw a validation or anything, it just didnt work.

I modified my fork to remove that parsing, and to be the same as the NPM version, committed, pushed, published, re made the image and re-pushed to my demo device and ive got a working OLED now.

Thank you so much @Colin