A feature that allows irrigation programs to be named has been added as of SIP version 4.2.28.
An input field is located at the top of the program set up page.
Program names appear on the program listing page, in log entries and in the legend at the bottom of the timeline on the home page.
After a crash of my PI, I have a problem with new installation. After installing “relay 16” plugin, I have still 8 station on main screen. Any help ?
In log I Have such error:
Problem switching relays list index out of range 19
Problem switching relays list index out of range 21
Problem switching relays list index out of range 23
Problem switching relays list index out of range 29
Problem switching relays list index out of range 31
Problem switching relays list index out of range 33
Problem switching relays list index out of range 35
Problem switching relays list index out of range 37
Howdy folks! Love the program! We are about to Impliment some crop steering using SIP.
I was wondering if there is a way to rename the programs? It would be beneficial to us as were will be adding about 15 different feeds for each room about 10 rooms. and each room with will 3 sets of differnt watering schedules based on times of the cycle.
As it stands they are listed as program 1, program 2 etc. We would like to be able to label them Flower 1 Transisition, Flower 1 bloom, Flower 1 Ripen. Etc.
Is this possible? Did I miss something simple? Also we are currnently still on 3.2.62 is it maybe in the newer versions?
Thank you kindly for any assistance anyone may be able to provide.
Astro Gerard has contributed an excellent plugin that allows for a large number is stations to be easily and inexpensively added to SIP.
It is called "pcf857x_plugin" and is available from the SIP plugins repo through SIP's plugin manager page. It used i2c and requires SIP to be running under Python 3.
Gerard is keen to receive user feedback on his plugin so please post here with any comments.
Is it possible to connect the master and slave controllers on different networks (i.e., with distinct public ip addresses)?
Here is what I have tried:
0. I installed mosquitto broker on my master controller.
1. I installed openvpn on the master controller so that I can access it from outside my home network via: http://master01.ddns:xxxx, where xxxx denotes port forwarding which I configure on my router.
2. On the master controller, for mqtt_bases setting:
broker host: localhost
broker port: 1883
...
Then to verify that the master can control the slave when they are on the same network:
3. On the slave controller, for mqtt_base setting:
broker host: 192.168.0.167 # which is the local ip address of the master controller
broker port: 1883
...
I have verified the above setup works as expected.
4. Now I put the slave controller on a different network, and try to connect to the master via the master's public ip address:
broker host: master01.ddns:xxxx
broker port: 1883
Actually I have tried various things for #4 but none works so far:
4a. broker host: master01.ddns:xxxx
4b. broker host: master01.ddns:1883 # of course I set my router to port forward 1883 as well
4c. broker host: master01.ddns
4d. broker host: http://master01.ddns:xxxx
4e. broker host: http://master01.ddns:1883
4f. broker host: http://master01.ddns
So I am wondering if I am attempting to do something that is not possible.
If not possible, what about using an online mqtt broker instead of a private one?
I haven't looked at the plugin codes yet, but do you know offhand if I need to modify anything?
I am hoping if I use the same topic for both publication and subscription, as the plugins do in mqtt_base for master and slave respectively, then maybe the plugins will work without modifications.
The combine_stations plugin uses the final set of 8 stations as virtual (combo) stations.
A complication arises when this plugin is used in conjunction with the mqtt_slave plugin.
The latter plugin requires adding n (=1,2,...) extension boards depending on how many equivalent boards the slave controller has.
For example, n=3 if slave has 16 physical channels and 8 virtual channels.
This number n is added to the master controller's "options/station handling/station extensions" setting.
To be concrete, in my setup, my master controller has 16 physical stations and 8 virtual stations.
V17-24 are for setting up virtual stations in the master controller.
If the slave_controller is introduced, the master controller has reassigned the virtual stations to V41-48.
So a user has to re-program the virtual channels every time a new slave controller is added.
Is it possible to automatically copy over the virtual stations assignment so that the content of V41 is copied from V17?
V17 >> V41
V18 >> V42
...
And to remove the original virtual assignments since they are no longer effective?
V17 --> S17
V18 --> S18
...
And also to repeat the process every time a new stations are added?
The library works with these drivers:
SSD1306 / SSD1309 / SSD1322 / SSD1325 / SSD1327 / SSD1331 / SSD1351 / SSD1362 / SH1106 / WS0010
I used the built-in functions in luma-oled library.
So I am able to shorten the code base, from 1488 lines to 700+ lines.
For reference, I make the following modifications on ssd1306.py.
The following three classes are all combined into one LCD class:
1. Screen
2. Screenblock
3. LCD
Some of the functions in ssd1306.py have corresponding functions in luma-oled library:
ssd1306 function --> luma-oled function
set_power(on=True) --> show()
_force_power_off() --> hide()
clear() --> clear()
The display syntax is also simplified.
Instead of the write_line() function specifying which lines to write on which row, and what font_size to use,
a new write_para() takes a block of text in one go and splits it into separate lines for display, and automatically calculates the appropriate font_size and row number for each line.
The text block contains a line separator -- semicolon followed by a space: "; "
For example, txt_block = 'line_1; line_2; [line_3]'
Any line_x too long is automatically further split via a wrap(width=wrap_width) function with a global wrap_width parameter specifying max number of characters per line.
So wrap_width is a factor that will determine font_size, but it is set once to apply globally to all lines.
I use wrap_width = 20 to allow for very long line (small font_size) for the short 128x64 display.
And wrap_width = 15 for larger text size on the tall 128x128 display.
The wrap_width is not configurable to avoid confusion; but can be made so if necessary.
See attached oled.luma.plugin.pdf for examples of txt_blocks.
Screen dimensions (height and width in pixels) are pre-configured in the drivers. So no need to provide configuration settings.
The 'rotate' setting allows for display rotation in 90degree increments.
I use i2c_write_addr (e.g. 0x3C) instead of the i2c_hw_addr (correspondingly 0x78), since the plugin does not need the latter.
And the former is conveniently accessible via the 'i2cdetect -y 1' command.
I have not tried a color oled (e.g. ssd1327, ssd1331, ssd1351).
The ssd1306 yellow-blue display is actually monochromatic in signal but is rendered different colors in the two areas.
The ssd1327 I have is capable of 4-bit grayscale. I have placed an order for an RGB version. Will try it out and report.
The sh1106 I have does not work properly: the top line is never displayed. I am not sure if I have a defective unit.
It would be interesting to see how well it works on other displays.
![[Image: pJfmGafSLz.jpg]](https://subirimagenes.s3.eu-central-1.wasabisys.com/subirimagenes/pJfmGafSLz.jpg)
