I need advice on how to implement a water leak protection using Chipi

[svetlyak40wt]

I have a few zigbee leak sensors and a two relays for controlling the valves.

I can already have a lisp code for reading sensors state from MQTT server and relays also will be controlled by publishing values to MQTT.

The questions:

1. MQTT library uses a cl-async and requires to run a loop in a separate thread. How to integrate such thread into the Chipi's actor system?

2. How to configure Chipi to act like this?

   1. If any leak sensor reports `true`, then
   2. Remember it should turn off water valves in nearest 30 seconds
   3. Publish true to a few MQTT topics to start turning water off
   4. After the 30 seconds publish false to a few MQTT topics to turn off valve motors.
   
   1. If all leak sensors reports `false` and we are not turning water off
   2. Remember we should turn water on in nearest 30 seconds
   3. Publish true to other MQTT topics to start turning water on
   4. After the 30 seconds publish false to a few MQTT topics to turn off valve motors.
   
   It would be cool to store sensors state and flags if we are turning water on/off between service restarts. In this case we should ensure the correct values are published to relay topics until the timeout.
   

[mdbergmann]

A Chipi setup can be just one CL file. The Chipi setup begins at DEFCONFIG.

Any additional setup (MQTT library) can be done prior to or as part of DEFCONFIG, i.e. in EVAL-WHEN at the top or as DEFCONFIG macro body.

I sounds like that the zigbee sensors as well as the relays should be Chipi items.

Regarding question 1:

The easiest integration could be done via items that represent/map the sensors/relays.
When you have a MQTT runloop which receives changes of the sensors you could call SET-ITEM-VALUE on the item that represents the sensor.

Once the connection between zigbee sensor and Chipi item is established one could use a DEFRULE to listen on sensor changes which allows to implement the workflows you mentioned.

Items can persist their value and restore that value on startup by having something like this:

(defpersistence :simple
  (lambda (id)
    (make-simple-persistence id :storage-root-path #P"some-path")))

(defitem 'mysensor "My XYZ Sensor" 'integer
  :initial-value 0
  :persistence '(:id :simple
                 :frequency :every-change
                 :load-on-start t)

Items without any bindings are basically just value containers. Once you add a binding you can control what should be done in case the item value changes.

For example:

(defitem 'mysensor "My XYZ Sensor" 'integer
  :initial-value 0
  (binding :push (lambda (value)
                    (when value
                      ;; 2. Remember it should turn off water valves in nearest 30 seconds
                      ;; 3. Publish true to a few MQTT topics to start turning water off
                      ;; 4. After the 30 seconds publish false to a few MQTT topics to turn off valve motors.
                    ))
           :call-push-p t)  

But maybe this better be a RULE. Hard to say from the distance.

Of course there can be a more tight zigbee integration as a plugin with zigbee related DSL like the one I did for KNX (https://github.com/mdbergmann/chipi/blob/main/bindings/knx/README.md).

Not sure this all answered your questions fully.
Let me know if not.

[svetlyak40wt]

Is it possible to make a stateful objects in Chipi?

For example, I have idea to create a VALVE-CONTROLLER object which will have states like :OPENED :CLOSED :OPENING :CLOSING and should react on messages :OPEN and :CLOSE.

Depending on it's state, VALVE-CONTROLLER should process. For example, if it is already :CLOSING, then another :CLOSE message should be ignored.

I think it might be implemented as a Sento actor, or maybe Chipi has more suitable abstraction?

[svetlyak40wt]

Another example of such state object is an object which will decide to close or to open the valve.

I have a multiple leak sensors as inputs and the following rules:

• if at least one sensor changed its value to true, then we need to close the valve.
• if all sensors are changed their values to false, then we need to open the valve.

And it is impossible to implement the second rule without looking to the state of all sensors.

Should I use defrule which will trigger on multiple values change but in the body of the trigger to check current values of all items it is subscribed using item:get-value function?

[mdbergmann]

Stateful objects in Chipi are items. An item can have any value, so also one of :OPENED :CLOSED :OPENING :CLOSING.
But a 'rule' is required to implement the state actions.

(defitem 'valve-controller-item "Valve Controller"
  :initial-value :CLOSED)

(defrule "My value-controller-rule"
  :when-item-change 'valve-controller-item
  :do (lambda (trigger)
         (let ((item (cdr trigger)))
             ;; asynchronously do something with the value
             (future:fcompleted (item:get-value item)
                 (value)
               (case value
                 (:OPENED ...)
                 (:OPENING ...)
               ;; etc.
               )))

That way you automatically have value persistence.

Should I use defrule which will trigger on multiple values change but in the body of the trigger to check current values of all items it is subscribed using item:get-value function?

Yeah, I would probably do that.
As a convenience you can define groups where get-value on a group will retrieve values of all group items.

[mdbergmann]

There are some convenience getters here: https://github.com/mdbergmann/chipi/blob/main/src/hab.lisp , i.e.: get-item-valueq. Since value retrieval on the item is so fast that the future (and item:get-value) is not required.