Manual input position of the sun

[mvandenabeele]

I'm testing the blind-control node and I would like to evaluate its behavior based on different positions of the sun. It would be nice if I could feed the sun position through the input. From the moment a "manual" sun position is received, the node should no longer calculate the position of the sun on its own until the node is reset.

[mvandenabeele]

I guess a similar way to override/set the time would be handy too.

[Hypnos3]

Specifying a sun position externally would be a major effort. Since I don't see any use case for this either, it looks bad.

What you can do is calculate your desired position by your sun position and feed this as a manual override.

[mvandenabeele]

I understand it's more of a code quality problem. That's why I was looking for it in the first place. I've been using your node for a reasonable time now, and every time there's an update, I'm afraid it will break things. I have a bug report open now about rules, but issues like that have been happening in the past. My conclusion was to set up a separate node-red instance with some test scripts, so I can verify all my situations are covered. A manual override is not a solution to this problem. As more and more people use your node, this will become more and more important. I know you're probably doing this in your free time and I'm very grateful for that. I'm willing to help refactor if you like.

[mglaabde]

@mvandenabeele: I share your concern. I'm wondering that it seems like automatic test cases for node-red in general is rarely supported. My setup is, besides others, home assistant, node-red, MariaDB, InfluxDB, homematic: I'd love to utilize the replay of historical data available on MariaDB and InfluxDB, when I'm developing/improving node-red automations, and when node-red packages are updated. Controlling blinds based on sun position, illumination, wind speed and directions, presence, TV status, really can lead to various edge cases that are not easy to find or solve. So far, I wasn't able to find anything meaningful for that. I'm really surprised that this kind of professionalism for development and maintenance has not yet been in focus within node-red and home assistant.

[Hypnos3]

There is no code quality problem here. A design decision is that basic functions are provided by the position node. This includes, among other things, the calculation of the position of the sun, whereby this node in turn uses an internal library for the sun position calculation. This library gives not a "simple value" for the sun-positon, but a complex object:

{
    azimuth,
    altitude,
    zenith,
    azimuthDegrees,
    altitudeDegrees,
    zenithDegrees,
    declination
}

These calculated values are also cached to avoid unnecessary double calculations. All nodes that use the same position node use this data. Due to this strong encapsulation, it is not so easy to specify the position of the sun through the input of a node by a "simple value". It would still be easiest if the complete object for the sun-position were transferred via the input.

But I still see no use case therefore to specify the sun position. For the "sun-position" and the "moon-position" node itself it is already possible to specify a different position (latitude and longitude ). It would be relatively easy to enable this for the other nodes as well.

testing

The internal library can be tested completely without anything else and that's what I do when I make changes there. For the testing of the nodes themselves, I have currently only provided that you can specify the date and time (this works with all nodes). To test different sun-positions I normally test simply with different times. I have a collection of test cases. For tests with different sun positions I test the internal library separately and for integration tests I have different position nodes.

automatic tests and refactoring

Node-red already support to include unit-tests (e.g. automatic test) node packages and I have already planned to include such automatic test cases sometime when I have time for it. This is on the backlog for a very long time.

In the backlog are some planned refactoring:

• further merging of the code base of the blind-control node with the clock-timer node.
• separation of the internal library as an own independent npm library

In the case of far-reaching changes, I have always provided beta versions for a longer period of time and there are also willing users who test them in advance.