Omkeerbeveiliging Zwave

[JustinoFTW]

Mijn vraag
Ik heb momenteel een Qubino Shutter DC in mijn netwerk die een paal bedient, die omhoog/omlaag kan.

Nu is het zo dat, mocht er om wat voor reden dan ook iets opstaan, bijv een auto, dan zou ik graag willen dat de qubino weer naar beneden gaat als een omkeer beveiliging.

De paal heeft 10 seconde nodig om van beneden naar boven te gaan. Als er dus bijvoorbeeld op seconde 7 seconde al tot stilstand komt dan zou het fijn zijn als er een commando naar toe gaat om weer naar beneden te gaan.

Relevante software en hardware die ik gebruik
Raspberry Pi
Home Assistant (incl ZWave JS to MQTT)
Aeotec Gen5 zwave stick

Wat ik al gevonden of geprobeerd heb
Home Assistant automation proberen te maken dat indien de paal na 5 seconde al stopt, i.p.v de 10 seconde die hij nodig heeft, dat de qubino dan weer een Down commando geeft.
Deze automation krijg ik helaas niet voor elkaar, omdat ik niet helemaal weet dat ik doe in die Automations.

[Septillion]

Ik heb geen weet van Qubino maar wel van HA. Hoe kan je daar zien of de paal gestopt is of niet? En kan je een voorbeeld geven wat je in HA geprobeerd hebt?

[JustinoFTW]

Septillion schreef op donderdag 17 maart 2022 @ 11:36:
Ik heb geen weet van Qubino maar wel van HA. Hoe kan je daar zien of de paal gestopt is of niet? En kan je een voorbeeld geven wat je in HA geprobeerd hebt?

Zover ik weet geeft de Qubino een stop commando zodra er te lang teveel vermogen op staat. Daarmee heeft de Qubino door dat de eindstand is bereikt (los van of dit ook daadwerkelijke eindstand is, dus niet meer verder omhoog kan)

Ik heb uit frustratie de automation weggegooid omdat ik het niet voor elkaar kreeg, dus ik heb daar momenteel geen voorbeelden meer van. Kort samengevat werkte geen van alle.

[Septillion]

Misschien mijn gebrek aan Zwave kennis, maar hoe manifesteert dat zin in HA?

En hoe start en stop je het bewegen in HA?

[JustinoFTW]

Septillion schreef op donderdag 17 maart 2022 @ 11:53:
En hoe start en stop je het bewegen in HA?

Zodra de Qubino toegevoegd is aan HA krijg je de volgende knoppen.
Daarmee kan je de paal/qubino bedienen.


Daarnaast heb je dan ook nog de stroom sensor, welke het verbruik bijhouden. Zodra de Wattage hoog oploopt, dus bij het einde, stopt de Qubino met "draaien".

[Septillion]

Heb je ook nog een sensor die de staat van de shutter aangeeft? Misschien wel in de cover zelf, kan je die eens laten zien in de dev tools?

[ Voor 37% gewijzigd door Septillion op 17-03-2022 12:07 ]

[tlpeter]

Bij een Fibaro roller/shutter kun je een kalibratie uitvoeren. Als ik het goed heb dan stopt de module bij teveel weerstand.

[JustinoFTW]

tlpeter schreef op donderdag 17 maart 2022 @ 12:08:
Bij een Fibaro roller/shutter kun je een kalibratie uitvoeren. Als ik het goed heb dan stopt de module bij teveel weerstand.

Klopt, dat bedoel ik inderdaad.
Wat ik graag zou willen is als deze stop eerder is dan 10 seconde dat de paal dan weer naar beneden gaat.

[Sitelabs]

Dit soort veiligheidsfuncties wil je in de paal hebben toch? Ipv bij een controller waarbij verbinding en response niet gerandeerd is?

[JustinoFTW]

@Sitelabs dat zou ook nog een opties kunnen zijn.
Ik zou alleen niet weten hoe ik dat moet aanpakken, heb je enige suggesties/ervaringen?

[Septillion]

Stoppen lijkt me de grootste veiligheidsfunctie en dat zit dus al in de paal.

Denk nog steeds dat het prima in HA kan maar moet je even wat meer info delen.

[JustinoFTW]

@Septillion de paal heeft in dit geval 5 aders, waarvan ik de + en -, welke d.m.v omgekeerde polariteit dus up en down worden. De Qubino is degene welke stopt na weerstand, de paal/motor is in dit geval "dom".

De andere 2 aders weet ik helaas de functie niet van, en heb ook geen documentatie van de "motor".
Het is een "linear actuator motor" welke op internet zoekende 2 aders zou moeten hebben. Echter heeft deze er dus 5. Kan even kijken of ik er een kan open maken.

Wat betreft de meer/extra info, wat zou ik eventueel kunnen aanleveren om het duidelijk te maken? Dan ga ik daar voor zorgen.

[ Voor 11% gewijzigd door JustinoFTW op 17-03-2022 15:09 ]

[Septillion]

Bedoel niet zo zeer de hardware, als dat werkt geloof ik dat wel. Maar waarschijnlijk kan je met de andere twee de positie uitlezen (maar niet met de Qubino Shutter DC).

Ben verder ook geen Qubino of Zwave expert dus of je het daarin op kan lossen, geen idee. Het klinkt niet als iets super voor de hand liggends dus zou het niet zo verwachten.

Maar waar ik wel veel van weet is HA alleen zal ik wat meer info moeten hebben van want de entiteiten van de shutter in HA werkelijk zijn. Kan je "Flush Shutter DC" en "Flush Shutter DC: Electric Consumption [W]" laten zien als je ze toont in Dev tools -> States.

[JustinoFTW]

@Septillion ik krijg deze info uit de dev tools.


De Qubino in dit geval:
https://qubino.com/products/flush-shutter-dc/


Wat betreft de motor, die heb ik even losgemaakt om de aders te bekijken.
Zie hier als volgt:

[ Voor 20% gewijzigd door JustinoFTW op 17-03-2022 15:53 ]

[Septillion]

Je hebt er één getoond die ik vroeg en één die ik niet vroeg De belangrijkste, de werkelijke shutter, laat je nog niet zien.

[JustinoFTW]

@Septillion excuus! 2 dingen tegelijk doen is niet mijn sterkste kant.
Ik heb mijn vorige reactie even bijgewekt om het overzichtelijk te maken

[Septillion]

Is het heel erg als ik de shutter entity nog steeds niet zie

[JustinoFTW]

Septillion schreef op donderdag 17 maart 2022 @ 21:14:
Is het heel erg als ik de shutter entity nog steeds niet zie

Sorry, ik dacht dat je de Qubino Shutter module bedoelde.
Ik snap nu de verwarring ook denk ik. In dit geval is de pen-motor (inline actuator) de "shutter" die op en neer gaat en daar zit dan de paal/beugel aan vast.

[Septillion]

Haha, de verwarring is volgens mij nog steeds niet weg Ik bedoel geen hardware. Maar deze entity:


Die zou ik graag incl alle attributen in de dev tool zien. Dat is immers de entity waarmee je de boel aanstuurt.

[Verwijderd]

Geen idee hoe dat met zo'n shutter module precies werkt, maar bij een dimmer kon ik in Domoticz altijd uitlezen hoe "fel" deze stond. Als deze module niet iets heeft waaraan je zou kunnen zien hoe ver de paal omhoog is gekomen, dan zul je dat al lastiger moeten gaan bepalen.

Kun je bepalen dat de module na bijv. 5 seconden stopt? Je wil hem eigenlijk laten stoppen voordat het Wattage aan het eind oploopt. Want als je dat in de normale operatie kunt voorkomen, kun je dat gebruiken als trigger voor een blokkade. Dus.... als module hoog wattage geeft, dan weer down.

Andere route: kun je middels een externe sensor bepalen dat de paal maximaal omhoog is gekomen? Want dan: module geeft hoog wattage -> check externe sensor -> if sensor zegt "paal staat maximaal omhoog" doe niets, else down.....

Misschien nog een creatief idee: Heeft de module terminals waarop je een pulsdrukken aan zou kunnen sluiten? Dan heb je geen externe sensor nodig. Dan kun je een mechanische stop bouwen met een pulsdrukker die bij indrukken een korte puls geeft. Je zorgt dan dat die pulsdrukker "afgaat" net voor de paal op de maximale stand komt. Dan voorkom je ook het ontstaan van een hoog wattage op de module. Dan kun je dat wattage dus wel als trigger gebruiken voor een blokkade en daar weer een actie aan knopen.

[ Voor 23% gewijzigd door Verwijderd op 18-03-2022 10:53 ]

[JustinoFTW]

Septillion schreef op vrijdag 18 maart 2022 @ 10:33:
Haha, de verwarring is volgens mij nog steeds niet weg Ik bedoel geen hardware. Maar deze entity:
[Afbeelding]

Die zou ik graag incl alle attributen in de dev tool zien. Dat is immers de entity waarmee je de boel aanstuurt.

Dan nu hopelijk de juiste.

Het is echter wel zo dat de 0 en 99 niet heel accuraat zijn. Als ik de de paal/beugel omhoog doe komt deze op 99 te staan. Hou ik de beugel halverwege tegen, bijvoorbeeld in het midden, dan kan het zo zijn dat deze op 80 of op 30 staat. Die calibratie werkt niet lekker jammer genoeg.

Verwijderd schreef op vrijdag 18 maart 2022 @ 10:43:
Geen idee hoe dat met zo'n shutter module precies werkt, maar bij een dimmer kon ik in Domoticz altijd uitlezen hoe "fel" deze stond. Als deze module niet iets heeft waaraan je zou kunnen zien hoe ver de paal omhoog is gekomen, dan zul je dat al lastiger moeten gaan bepalen.

Kun je bepalen dat de module na bijv. 5 seconden stopt? Je wil hem eigenlijk laten stoppen voordat het Wattage aan het eind oploopt. Want als je dat in de normale operatie kunt voorkomen, kun je dat gebruiken als trigger voor een blokkade. Dus.... als module hoog wattage geeft, dan weer down.

Andere route: kun je middels een externe sensor bepalen dat de paal maximaal omhoog is gekomen? Want dan: module geeft hoog wattage -> check externe sensor -> if sensor zegt "paal staat maximaal omhoog" doe niets, else down.....

De kalibratie optie zelf werk niet lekker maar je kan het inderdaad ook manueel kalibreren. Zowel omhoog als omlaag is precies 7,5 seconde, wat ik dus ook heb ingesteld. Daarmee voorkom je inderdaad de oplopende wattage op het einde.
Enig idee hoe ik deze trigger het beste kan configureren? Ik heb tot nu toe alleen maar met Automations gewerkt, de Scenes en Triggers zijn nieuw voor mij.

Die externe sensor zou wellicht een optie zijn, ik zou alleen niet weten hoe ik daar mee moet beginnen en of het te combineren is met de Qubino.
De motor heeft 5 adres waarvan ik nu alleen + en - gebruik. Dus wellicht is er meer mee mogelijk.

[Septillion]

Kijk, ik wilde inderdaad weten of en hoe de shutter de positie laat zien. Ik heb nog geen HA draaien naar de verhuizing en daar ik graag automations met de UI maakte is dat nu even lastiger. Maar wat ik zou doen in pseudio code:

code:

trigger: cover.flush_shutter_dc[current_position] > 0
action:
- wait while sensor.flush_shutter_dc_powerconsuption_w > 5
- if position < 100
  - cover.flush_shutter_dc to position 0

Ofwel in woorden, als de shutter omhoog gaat (boven positie 0 uit komt), dan wachten zolang de motor nog vermogen gebruikt. Zodra dat stopt, dus de motor staat stil, kijken of hij op 100% is gekomen. Zo niet, dan doen we hem weer omlaag.

Als 0% en 100% positie wat onnauwkeurig zijn zou je ook gewoon iets meer marge kunnen nemen, 5% en 95% ofzo.

[JustinoFTW]

@Septillion dankje! Ik ga het straks gelijk even testen!
Koppel het daarna hier terug.

[Septillion]

Even uit de losse pols wat yaml:

YAML:

alias: "Retract flush_shutter_dc if stopped early"
trigger:
  - platform: numeric_state
    entity_id: cover.flush_shutter_dc
    attribute: current_position
    above: 0
condition: []
action: 
  - wait_for_trigger:
    - platform: numeric_state
      entity_id: sensor.flush_shutter_dc_electric_consumption_w
      below: 5
      timeout: "00:00:11"
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: cover.flush_shutter_dc
            attribute: current_position
            below: 100
        sequence:
          - service: cover.close_cover
            entity_id: cover.flush_shutter_dc
    default: []

Bedenk me wel, dit gaat er wel vanuit dat de positie dus al geüpdatet wordt tijdens het bewegen. Als de positie alleen wordt doorgegeven als de shutter is gestopt is het zelfs nog makkelijker. Dan zou je gewoon altijd hem weer kunnen openen als je een positie anders dan 0% of 100% (of dus >5 en < 95) ziet.

[ Voor 17% gewijzigd door Septillion op 18-03-2022 11:34 ]

[JustinoFTW]

Septillion schreef op vrijdag 18 maart 2022 @ 11:31:
Even uit de losse pols wat yaml:

YAML:

alias: "Retract flush_shutter_dc if stopped early"
trigger:
  - platform: numeric_state
    entity_id: cover.flush_shutter_dc
    attribute: current_position
    above: 0
condition: []
action: 
  - wait_for_trigger:
    - platform: numeric_state
      entity_id: sensor.flush_shutter_dc_electric_consumption_w
      below: 5
      timeout: "00:00:11"
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: cover.flush_shutter_dc
            attribute: current_position
            below: 100
        sequence:
          - service: cover.close_cover
            entity_id: cover.flush_shutter_dc
    default: []

Bedenk me wel, dit gaat er wel vanuit dat de positie dus al geüpdatet wordt tijdens het bewegen. Als de positie alleen wordt doorgegeven als de shutter is gestopt is het zelfs nog makkelijker. Dan zou je gewoon altijd hem weer kunnen openen als je een positie anders dan 0% of 100% (of dus >5 en < 95) ziet.

Ik krijg tijdens het toevoegen de volgende fout:
Message malformed: extra keys not allowed @ data['timeout']
Zonder deze regel accepteert HA het wel, dus ik zal deze even testen.

Als ik het goed heb, maar dat moet ik zo even controleren, geeft de Qubino een 0 stand zodra deze beneden stopt. En als deze boven stopt is dit positie 99. Aangezien het manuele kalibratie is, kan dit ook wel kloppen.
Heb het idee dat we zo wel dichtbij zijn tot de oplossing!

[Septillion]

Oeps, die hoort niet bij de 'numeric_state' maar bij 'wait_for_trigger'. Moet één indent naar links dus:

YAML:

alias: "Retract flush_shutter_dc if stopped early"
trigger:
  - platform: numeric_state
    entity_id: cover.flush_shutter_dc
    attribute: current_position
    above: 0
condition: []
action: 
  - wait_for_trigger:
    - platform: numeric_state
      entity_id: sensor.flush_shutter_dc_electric_consumption_w
      below: 5
    timeout: "00:00:11"
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: cover.flush_shutter_dc
            attribute: current_position
            below: 100
        sequence:
          - service: cover.close_cover
            entity_id: cover.flush_shutter_dc
    default: []

Maar zie je tijdens het bewegen geen positie?

[JustinoFTW]

Septillion schreef op vrijdag 18 maart 2022 @ 11:40:
Maar zie je tijdens het bewegen geen positie?

We zijn er bijna denk ik!
Zodra de beugel omhoog gaat en ik hou hem tegen, dan gaat deze daarna weer naar beneden!
Echter op eindpositie boven ook, dus ik moet even kijken hoe ik dat aanpak.

De trigger heeft een "above 0" waarde maar na het opslaan wordt deze elke keer leeggehaald. In de YAML editor staat er dan wel weer 0

Wat betreft de positie, zodra het commando Up gegeven is komt de waarde 100 te staan en daarna een tussenwaarde van bijvoorbeeld 61 of 65.

Met het huidige script eindigt de paal/beugel altijd op positie 0

[ Voor 10% gewijzigd door JustinoFTW op 18-03-2022 12:06 ]

[Septillion]

Zou je kunnen laten zien wat HA er van maakt na het opslaan?

[Verwijderd]

Below 100. Jouw module geeft 99.

[JustinoFTW]

Septillion schreef op vrijdag 18 maart 2022 @ 12:24:
Zou je kunnen laten zien wat HA er van maakt na het opslaan?

Precies hetzelfde, cop-paste uit HA:

code:

alias: Retract flush_shutter_dc if stopped early
trigger:
  - platform: numeric_state
    entity_id: cover.flush_shutter_dc
    attribute: current_position
    above: 0
condition: []
action:
  - wait_for_trigger:
      - platform: numeric_state
        entity_id: sensor.flush_shutter_dc_electric_consumption_w
        below: 5
    timeout: '00:00:11'
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: cover.flush_shutter_dc
            attribute: current_position
            below: 100
        sequence:
          - service: cover.close_cover
            entity_id: cover.flush_shutter_dc
    default: []

Verwijderd schreef op vrijdag 18 maart 2022 @ 12:26:
Below 100. Jouw module geeft 99.

Dat dacht ik, maar is toch 100. Ook als de waarde op 95 staat doet deze het.

[Septillion]

Wat bedoel je dan met:

JustinoFTW schreef op vrijdag 18 maart 2022 @ 12:03:
De trigger heeft een "above 0" waarde maar na het opslaan wordt deze elke keer leeggehaald. In de YAML editor staat er dan wel weer 0

Wat zou kunnen is dat het toch net wat langer duurt en hij dus door gaat op de timeout. Je zou die timeout eens kunnen verlangen naar een minuut ofzo.

En als de module eindigt op 95% dan is het toch correct dat deze weer naar beneden gestuurd wordt?

[Verwijderd]

Dan gok ik inderdaad op een te vroege trigger (paal gaat omhoog, module geeft 10...20...30...40....50...60... etc), waarna hij in de rest van 't script dezelfde waarde gebruikt als in de trigger. Dus de trigger "trapt af" op 10, wacht daarna op een power consumption van <5W en toetst dan met 10. En doet het paaltje weer naar beneden, want beneden 100, 95, 90 of 80....

@Septillion : Volgens mij verlaagt hij de waarde in het script, dus "below 95".

[Septillion]

@Verwijderd HA toetst zeker niet met de waarde tijdens trigger. Sterker nog, als je specifiek de trigger waarde wilt weten zal je dat echt af moeten vragen als to_state als je denk dat het een fractie later (in een conditie of actie) al anders kan zijn.

En in de geposte code van hem zie ik geen aanpassingen. Dus als hij bij correct omhoog gaan ook kan eindigen met 95% dan zal dat inderdaad aangepast moeten worden in de code. Code gaat er nu vanuit dat allen lager dan een eindpositie van 100 niet goed is en dus weer omlaag moet.

[Verwijderd]

Dan ben ik inderdaad benieuwd naar de power consumption na 11 seconden.

Ik ben geen HA gebruiker en vanwege een verhuizing gebruik ik al meer dan een jaar geen Domoticz meer (vorige week toevallig mijn eerste 2 Fibaro dimmers weer ingebouwd, dus dat zal een kwestie van tijd zijn voor ik weer een controller ga bouwen. Maar als ik het goed begrijp, wacht hij nu 11 seconde op een trigger en gaat alsnog uitvoeren als die dan niet komt. Correct?

[Septillion]

@Verwijderd Ja, dus na 11 sec gaat hij altijd door met de rest. Je kan met continue_on_timeout: false ook de hele automation laten stoppen als de trigger niet komt. Maar daar ik na de wait nog weer check op een conditie in een chooser mag hij van mij altijd doorgaan.

Dat zo gezegd hebbende verwacht ik eigenlijk niet dat de timeout een probleem is. (Eigenlijk wel maar dat komt zo...) Want volgens @JustinoFTW wordt de positie al direct 100 zodra hij het commando geeft om omhoog te gaan. Pas nadat hij eerder stopt komt die <100 positie door. Dus als hij na 11 seconden dus nog steeds stroom ziet zal de wait wel stoppen maar zal de conditie erna (below 100) dus ook niet waar zijn.

Wel is dit natuurlijk eigenlijk een probleem, want je wilt dus eigenlijk dat als hij er te lang over deed dat hij ook echt terug gaat. Tweede beveiliging dus. Kan wel, kunnen we later nog naar kijken.

Voor nu denk ik dus vooral dat hij inderdaad gewoon niet altijd 100 aangeeft zodra hij volledig omhoog is. Dus dat hij na het indrukken om omhoog te gaan hij wel eerst direct naar 100 gaat maar zodra hij correct bovenaan is gestopt dat hij misschien toch maar 99 aangeeft. Je zou de grens die als correct gezien wordt dus wat kunnen verlagen.

offtopic:
En ken het, de eerste modules zitten hier wel weer in de muur maar met meer gaten voor stopcontacten dan lampen (twee ) in de woonkamer heeft HA opstarten nog geen zin gehad. Maar kijk er wel naar uit en Ms. Septillion nog meer

[Verwijderd]

Ik kan niet wachten tot het moment dat ik liggend op bed weer mijn "hey google, all lights off" kan afvuren. Nu is het te vaak "kak, de lamp in de gang is nog aan, kan ik weer naar beneden". En dat bijstellen van die analoge tijdschakelaar voor de buitenverlichting achter ben ik ook alweer beu.

[JustinoFTW]

Septillion schreef op vrijdag 18 maart 2022 @ 14:16:
Want volgens @JustinoFTW wordt de positie al direct 100 zodra hij het commando geeft om omhoog te gaan. Pas nadat hij eerder stopt komt die <100 positie door. Dus als hij na 11 seconden dus nog steeds stroom ziet zal de wait wel stoppen maar zal de conditie erna (below 100) dus ook niet waar zijn.

Het stukje om de beugel naar positie te brengen werkt perfect, maar inderdaad de beugel laten staan op positie Up lijkt nog niet helemaal goed te functioneren.

Ik ga, jammer genoeg, maandag even verder met het spelen hiermee.
Mocht je hier eventueel nog aanvullingen of optimalisaties hebben daar hoor ik dat natuurlijk graag

In ieder geval alvast bedankt voor de hulp tot zover! Zonder was ik hier niet op uit gekomen.

Verwijderd schreef op vrijdag 18 maart 2022 @ 14:31:
Ik kan niet wachten tot het moment dat ik liggend op bed weer mijn "hey google, all lights off" kan afvuren. Nu is het te vaak "kak, de lamp in de gang is nog aan, kan ik weer naar beneden". En dat bijstellen van die analoge tijdschakelaar voor de buitenverlichting achter ben ik ook alweer beu.

Ik ben zelf inderdaad ook nog flink bezig thuis, maar de tijd moet ik er nog voor vinden. En dan komt de WAF (Wife Acceptance Factor ) er natuurlijk ook nog bij kijken

[ Voor 25% gewijzigd door JustinoFTW op 18-03-2022 14:54 ]

[JustinoFTW]

@Septillion excuus voor de late reactie. Tijd op vakantie geweest en er daarna nog niet echt tijd voor gemaakt. Hopelijk heb je nog tijd/zin om eventueel mee te denken.

Een vriend van mij heeft de "omkeerbeveiliging" in OpenHab geprobeert en samen met een SQL database heeft hij de werking aan de praat gekregen. Hij weet alleen zelf niet hoe hij dit moet vertalen naar HomeAssistant.

Wat er inprincipe gebeurt is dat de beugel in omlaag staat naar omhoog stand gaat, en gedurende 6 seconde kijkt of de weerstand, als zijnde Amperage die omhoog gaat i.v.m weerstand, dan krijgt dezelfde beugel een "omlaag" commando.
Dus als de beugel binnen 6 seconde al ergens tegen aan komt gaat deze omlaag, als beveiliging.

Hierbij het stukje SQL. Is dit iets wat als automation/script te maken is in HomeAssistant?

code:

set nocount on;
declare @1 nvarchar(50)
set @1 = (SELECT TOP (1) Parkeerbeugels.Gekoppeld_Aan
FROM   empty.dbo.TMP_Edit_Beugel INNER JOIN
             empty.dbo.Parkeerbeugels ON TMP_Edit_Beugel.ID_Beugel = Parkeerbeugels.id
ORDER BY TMP_Edit_Beugel.ID DESC)


Select 'rule "' + @1   + ' Omhoog"' + CHAR(13) +
'when' + CHAR(13) +
'Item ' + @1 + ' received command ON' + CHAR(13) +
'then' +CHAR(13)+
'executeCommandLine("sudo python /etc/openhab2/scripts/' + @1 +'_omhoog.py")' +CHAR(13)+
'Thread::sleep(6000)' + CHAR(13)+
'if (' +@1+'.state == ON && '+@1+'_Power.state > 25)'+CHAR(13)+
'{' +CHAR(13)+
@1+'.sendCommand(OFF)'+CHAR(13)+
'}'+CHAR(13)+
'end'+CHAR(13)+
'rule "' + @1   + ' Omlaag"' + CHAR(13) +
'when' + CHAR(13) +
'Item ' + @1 + ' received command OFF' + CHAR(13) +
'then' +CHAR(13)+
'executeCommandLine("sudo python /etc/openhab2/scripts/' + @1 +'_omlaag.py")' +CHAR(13)+
@1+'.sendCommand(REFRESH)'+CHAR(13)+
'end'