For this installation I’ve designed PCB - 16 input , 16 output for one PCB but it can be extended for next PCB.
It looks that
Nice, do you want to improove it and sell it?
Probably next month I will order more PCB and if someone is interested I can sell it. Because I plan to order only small number, price is quite high around 4-5$ per PCB + cost of components.
1 Like
can you add holes for din clamp and add gnd to each gpio?
How din clamps look like? Adding GND to each I/O can be difficult PCB is only 80x100mm (limit of free Eagle) .
thanks for sharing. I’ve some comments.
Do not include these imports in OH 2.x
This could be just
Item RainSensor changed to OPEN
This could be just
Item RainSensor changed to CLOSED
Where is the definition of the RainSensor Item? I do not see it above in your items listing. Assuming it is a Contact, which is what it must be to use the from and to like this. Note the CLOSED and not CLOSE.
This applies across the whole rules file.
You could combine the two rules and save some lines of code if you wanted to.
Everything else was translated to English.
This could probably be significantly reduced by using a Map<String,Timer> and then looping through the members rather than reproducing the same lines of code over and over.
Move these to the top. You don’t want an error in the previous code to prevent your valves from turning off.
This can be reduced to
WtrLastDate.sendCommand(new DateTimeType)
You could use Design Pattern: Cascading Timers to make this part more generic which would make it easier for other users to adopt.
Without that, a lambda would be useful here to avoid duplicating code for each zone.
Could use a Timer for this rather than a polling cron trigger.
I would recommend using one of the Weather bindings for this rather than using HTTP directly. Or if it were acquired separately using HTTP, move this to a special weather set of rules so you don’t need to modify your irrigation rules if you choose to use a different weather service.
Thanks for sharing this example. There were only a few bugs and a few opportunities to make the code a little more generic.
1 Like
I would recommend to go for smd components(seedsudio among others can solder the pcb)
Maype the GPIO also should be optocoupled for the inputs
import org.openhab.core.library.types.*
import org.joda.time.*
Do not include these imports in OH 2.x
You are right but it helps when I develope code in SmartDesigne , without these import it displays errors.
You could use Design Pattern: Cascading Timers to make this part more generic which would make it >easier for other users to adopt.
I’ve almost rewrote whole code to use this pattern, after this change code is shorter about 100 lines but is definitly more complicated to understand and more complicated to debug. My watering installation has only 3 section in my situation what I’ve written is a trade off between flexibility and simplicity of code.
For sure I will put all timers to Map and I will use lambda expression and fix minor bugs. To be honest I’ve made all modification but I have to make final test 
Could use a Timer for this rather than a polling cron trigger.
I thought about Timers, but pooling has some adventages - it is simpler to test.
I would recommend using one of the Weather bindings for this rather than using HTTP directly. Or if it were acquired separately using HTTP, move this to a special weather set of rules so you don’t need to m
Good idea, but I have to check if this bindings offers exactly what I want - I need rainfall for next 24h
It shouldn’t since org.openhab.core.library.types no longer exist. Trying to include it should do nothing. Are you using Eclipse SmartHome Designer 0.8? Furthermore, using * in an import statement will generate a warning both in ESH Designer and in the OH logs.
There is often a trade-off between making code generic which requires the code to become a little more abstract. Abstract does not necessarily mean more complicated, but it is not always as straightforward. However, though it requires a little more work up front to understand, if done right, it becomes much easier to maintain and modify in the future.
You only have three zones but at least where I’ve lived, 5 or more is more typical (I have nine). For this reason, your example becomes much easier to adopt by other users if they can add new zones without needing to modify the rules. And this is primarily why I made the suggestion.
I don’t see Timers as any harder to test than polling.
I know for sure the Wunderground binding does. I beleive most if not all of the other bindings, except for maybe the Yahoo Weather Binding also offer this.
There is often a trade-off between making code generic which requires the code to become a little more >abstract
Yes you are right. For 15 years I was software developers and I know what do you mean.
But in my situation I wrote software for my garden not generic garden Second, I think we have many users on forum with limited knowledge about programming and they probably do not understand more advanced patterns and they can have problems to adopt code to specific needs. Usually people looking for what is easy to understand and easy use.
Your cascade pattern is more difficult to understand but off course for several section you are right is definitely better.
From my experience I can say that in some situation simpler code is better when you think about maintenance.
I don’t see Timers as any harder to test than polling.
Maybe not harder but simpler for me. During pooling I execute so little code that is also does not generate performance issue and I can exacly change how often my action can be performed.
But still thank you for your help , your advice is very helpful.
Michal
1 Like
True, but you posted it in Tutorials & Examples Solutions which implies you intended this posting to be something that others could take, use, and adopt to their system. With that assumption, I was looking for ways to make a user’s adoption of the the code require less work and less overall understanding. If the user need only copy the rule and create a bunch of Items and Groups it takes even less coding knowledge for them than requiring them to create new global variables and understand all the rules so they know where to copy and paste the right sections of code to add more zones.
But this section of the forum is also for the “I made this” type postings which your posting and I do thank you for contributing.
Except when you violate DRY you end up with a lot more opportunities to mess up when you want to change some behavior, fix a problem, or add more zones because you have to make the same changes in multiple places.
I agree that simpler code is easier to maintain, but I disagree that more abstract code is necessarily more complex in this regard.
1 Like
Dear Mr. Rich Koshak, Good Morning. I request you to publish your method of coding for a similar or a comparable Watering System for me Adapt my needs. I will also learn lot of coding technique from your posting.
Please help us with your for a learner like me.
Thanking you in advance.
With Great Regards,
Ragothaman R
Thank you so much and with Best regards.
Ragothaman R.
BTW includes are not necessary in 2.1 but I have strange behaviour in rule:
It does not work
var tmp= new Date()
it produce such error
2017-11-03 21:26:00.448 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule Watering_algorithm: An error occurred during the script execution: null
It works
var tmp= new java.util.Date()
and it also works
import java.util.Date
var tmp= new Date()
What imports are needed and which are not needed?
Only those imports I highlighted are not needed. I.e. those from org.openhab.core and org.joda. All other imports are required, including those from java.util.
How is it going with this project?
I’m looking for watering system for my house. Valeves are in place. I have older control system but without external connection. Still have few months to next seeson but it would be nice to plan something.
It is not a big project but few rules and items. Simply it works 
Michal
first of all, thank you for posting your project.
I was wondering if you have current version for OH 2.5 which you want to share with us?
Would like to use your code for my garden project.
Regards
Patrick
Hi bellow, most current version.
Sorry but comments are in Polish, without problem you can use google translate to translate to your native language. This version works without problem with 2.5. If you have question to code let me know.