Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


Search the Community

Showing results for tags 'quickapp'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • FIBARO Community
    • FIBARO Portal and Forum policy
    • FIBARO
    • Say hello!
    • Off-topics
  • FIBARO Update
    • FIBARO System Update
    • FIBARO Mobile Update
  • FIBARO Community Support
    • Scenes and Interface
    • FIBARO Products
    • FIBARO Mobile
    • FIBARO HomeKit
    • FIBARO Assistant Integrations
    • Other Devices / Third-party devices
    • Tutorials and Guides
    • Home Automation
    • Suggestions
  • FIBARO Społeczność
    • FIBARO
    • Przywitaj się!
    • Off-topic
  • FIBARO Aktualizacja
    • FIBARO System Aktualizacja
    • FIBARO Mobile Aktualizacja
  • FIBARO Wsparcie Społeczności
    • Sceny i Interfejs
    • FIBARO Urządzenia
    • FIBARO Mobilnie
    • FIBARO HomeKit
    • Integracja z Amazon Alexa i Google Home
    • Urządzenia Firm Trzecich
    • Poradniki
    • Automatyka Domowa
    • Sugestie

Categories

  • Scenes
  • Virtual Devices
  • Quick Apps
  • Icons

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Facebook


Google+


Skype


Website URL


WhatsApp


Country


Gateway/s


Interests

  1. Hello I am making an app that gets todays electric price hour by hour. I added an event for highest and lowest hour. Problems is that the setInterval(function() fibaro.emitCustomEvent("Lowpris") end, 3660*1000) and setInterval(function() fibaro.emitCustomEvent("Highprice") end, 3660*1000) emits one hour to late. setInterval sends 3660(one hour and 60 seconds after it should) and not sends it and then wait 3660 like intention was. The idea was to send then after 3660 the hour does not match the lowest hours so then the As now it does send after one hour and 60 seconds and it then send event emit every 10 seconds within the hour since the app restarts every 10 seconds do to because of. function QuickApp:onInit() fibaro.installFibaroExtra() setInterval(function() self:stromm() end, 10*1000) --10 = hvert 10 sekund oppdatering --fibaro.setTimeout(3660*1000, function() print("Kommer tilabkke om en time") end) end Is there any suggestions how to send and then wait over an hour to next check if current hour and lowest hour matches ? if not fibaro.existCustomEvent("HighPrice") then fibaro.createCustomEvent("HighPrice", tostring(highestPriceHour)) end --fibaro.emitCustomEvent("HighPrice") if not fibaro.existCustomEvent("Lowpris") then fibaro.createCustomEvent("Lowpris", tostring(lowestPriceHour)) end -- fibaro.emitCustomEvent("Lowpris") if fixtime == highestPriceHour then fibaro.createCustomEvent("HighPrice", tostring(highestPriceHour)) -- fibaro.setTimeout(3660*1000, function() fibaro.emitCustomEvent("Highprice") end) setInterval(function() fibaro.emitCustomEvent("Highprice") end, 3660*1000) print("high event made") else print("ingen høy event") end if fixtime == lowestPriceHour then --if local hour equals the lowest price hour then emit a signal fibaro.createCustomEvent("Lowpris", tostring(lowestPriceHour)) --fibaro.setTimeout(3660*1000, function() fibaro.emitCustomEvent("Lowpris") end) setInterval(function() fibaro.emitCustomEvent("Lowpris") end, 3660*1000) print("low event made") else print("ingen lav event") end end, -- success error = function(msg) self:debug('Error:'..msg) end -- error }) print("Klokken er nu "..timetest) end function fibaro.installFibaroExtra()local a="fibaroExtra"if fibaro.FIBARO_EXTRA then return end;local b="https://raw.githubusercontent.com/jangabrielsson/TQAE/main/lib/"..a..".lua"net.HTTPClient():request(b,{options={method='GET',checkCertificate=false,timeout=20000},success=function(c)if c.status==200 then local d={isMain=false,type='lua',isOpen=false,name=a,content=c.data}fibaro.debug(__TAG,"Installing ",a)local e,c=api.post("/quickApp/"..plugin.mainDeviceId.."/files",d)if c~=200 then fibaro.error(__TAG,"Installing ",a," - ",c)end else fibaro.error(__TAG,"Error ",c.status," fetching ",b)end end,error=function(c)fibaro.error(__TAG,"Error ",c," fetching ",b)end})end function QuickApp:onInit() fibaro.installFibaroExtra() setInterval(function() self:stromm() end, 10*1000) --10 = hvert 10 sekund oppdatering --fibaro.setTimeout(3660*1000, function() print("Kommer tilabkke om en time") end) end
  2. This QuickApp calculates the cheapest prices for using appliances based on the hourly Tibber energy prices. This QuickApp is especially useful for appliances (like charging your car and washing the dishes) that need to run once a day, within a timeframe and during some hours. You can use more than one instance of this QuickApp if you need more than one appliance to start in the cheapest hour but not within the same timeslot. Tibber today and tomorrow prices The tomorrow prices are available from 13:00 hour. If the tomorrow prices aren't available yet and the timeslot is (partially) tomorrow, a temporary calculation and start-stop plan is made with the today prices, until the tomorrow prices are available. If the start time plus duration is (partially) tomorrow, for example start time 18:00 and duration 7 hours, the calculation can be made from 13:00 hour when the tomorrow prices are available. At 04:00 the binary switch will turn ON and at 07:00 the binary switch will turn OFF. You would still have to create a script, triggers by this binary switch, to actually turn on the charging of your car, or turn on the dishwasher. IMPORTANT This QuickApp needs the Tibber Monitor QuickApp to run on your HC3. It is important to synchonise this QuickApp with the timing of your Tibber Monitor QuickApp. This QuickApp works at its best, if you setup the interval with the intervalOffset just after the Tibber Monitor runs. If you Tibber Monitor runs at 5 minutes (300 seconds) after the whole hour, run this QuickApp 5 minutes and 10 seconds (310 seconds) after the whole hour to be sure to get the prices from Tibber Monitor. This QuickApp runs every whole hour to turn the switch on and off. If it is time to get the prices from the Tibber Monitor QuickApp, this QuickApp runs every whole hour plus the seconds set in the intervalOffset. QuickApp logics onInit() getQuickAppVariables() createVariables() checkPrice() missionControl() If tibberChild0000 (Tibber Monitor Child devicenumber for "Today 00:00") doesn't exists --> disable QuickApp If current hour is hour to start --> turn the switch ON If current hour is hour to stop --> turn the switch OFF If current hour is 13:00 (tomorrowPrices) --> checkPrice() to check the prices again to calculate with the tomorrow prices and to plan a new start and stop hour If current hour is the end of the timeslot --> checkPrice() to check the prices again to plan a new start and stop hour updateLabels() every whole hour missionControl() (see above) etc DISCLAIMERS Use this QuickApp at your own risk. You are responsible for ensuring that the information provided via this QuickApp do not contain errors. Tibber is a registered trademark being the property of TIBBER. TIBBER reserves all rights to the registered trademarks. Information which is published on TIBBER’s websites belongs to TIBBER or is used with the permission of the rights holder. Making of copies, presentations, distribution, display or any other transfer of the information on the website to the public is, except for strictly private use, prohibited unless done with the consent of TIBBER. Published material on dedicated TIBBER press websites, intended for public use, is exempt from the consent requirement. Also see: https://tibber.com/en/legal-notice Tibber API documentation: https://developer.tibber.com/docs/guides/calling-api Tibber API explorer: https://developer.tibber.com/explorer Tibber status: https://status.tibber.com Variables (mandatory and created automatically) tibberChild0000 = The Tibber Monitor Child devicenumber for "Today 00:00" durationHours = How many hours should the switch be ON (not more than 23 hours) timeSlotStart = At which hour should the timeslot start timeSlotEnd = At what hour should the timeslot end tomorrowPrices = At what hour are the Tibber tomorrow prices available (default = 13) intervalOffset = The offset time in seconds to the interval of every whole hour (default 310 seconds) debugLevel = Number (1=some, 2=few, 3=all (default = 1) language = Preferred language (default = English (en)) (supported languages are English (en), Dutch (nl), German (de), Swedish (se) and Norwegian (no)) Changes version 0.3 (19th March 2024) Solved a small bug when timeslot end was greater than 23 hours Changes version 0.2 (15th February 2024) Optimized calculations and turnOn/TurnOff Added translations for Dutch (nl), German (de), Swedish (se) and Norwegian (no) Initial (beta) version 0.1 (11th February 2024) Initial beta version How to install Open the Configuration Interface Go to Settings > Devices Click + Choose Other Device Choose Upload File Choose file from your computer with .fqax Tibber_Trigger-03.fqax
  3. I want to do some normal validation of the UI (normal for people other than Fibaro which doesn't seem to understand the finer things of the user interface concepts). My immediate desire is to take two values from the UI and pass them both to the API where they will be processed. The device is a thermostat and is using the com.fibaro.hvacSystemAuto device type. This presents the user a heating setpoint and a cooling setpoint when the thermostat is in Auto mode. But when the "Set" button is pressed, it sends the heat setpoint as an action, then it sends the cool setpoint. But the API expects both setpoints when the device is in Auto. Further, it burps if the heat setpoint is hotter than the cool setpoint. Even worse, the device control is in the cloud so the round trip is quite slow. It appears that the heat setpoint property I retrieve using fibaro.getValue(self.id, "heatingThermostatSetpoint") doesn't appear to be the value which was just sent (and passed to the cloud) during the heat setpoint onAction() method [remember, BOTH values are sent to the API on each call]. My original idea was to adjust the current setpoints so that the cooling setpoint was 2° higher than the heating setpoint when that setpoint is about to be set if they are not already in a valid state. Then, during the cooling setpoint adjustment, I would change the heating setpoint to be 2° cooler than the cooling setpoint if they are not already in a valid state. Of course an even better solution would be to be able to peek at the other setpoint in the UI and send it. And ideally, I would like to be able to keep the state of the two setpoints in a valid state at all times. The app used by the thermostat adjusts the heating down if the cooling setpoint is adjusted down too much or it adjusts the cooling up if the heating setpoint is adjusted up too much. So it would be good practice to do something similar in the Fibaro UI. 🙄 But that's not likely to happen anytime in my lifetime or my children's lifetimes either. The code I'm using is: elseif (self.properties.thermostatMode == "Auto") then self:debug('Original coolingThermostatSetpoint ' .. self.properties.coolingThermostatSetpoint) -- The coolingThermostatSetpoint must be greater than the heatingThermostatSetpoint. -- Since both the heating and cooling setpoints are updated individually but the -- API must be adjusted for both values at the same time, there are problems when -- the heating setpoint is hotter than the cooling setpoint. Solution (for now) is to -- adjust the coolingThermostatSetpoint to be 2° higher than the new heatingThermostatSetpoint. -- **Note: If the user has not set these two setpoints correctly, the actual heating and cooling -- setpoints will reflect a 2° difference from whichever setpoint has been called last. local coolValue = fibaro.getValue(self.id, 'coolingThermostatSetpoint') self:debug(string.format("getValue() returned %f", coolValue)) if coolValue <= roundedHeatValue then coolValue = roundedHeatValue + 2 end My first pass used the self.properties.coolingThermostatSetpoint value. Then I tried the call to fibaro.getValue() but that didn't seem to help either. The code to set the cooling setpoint is a duplicate of the above except the heating setpoint is adjust downward by 2 vs. the cooling setpoint being adjusted upward. So what am I doing wrong? Thanks in advance to any ideas or solutions. Peter PS: After working on this some more I FINALLY recognized this is a symptom of the async nature of web communication. Both setpoints are called back to back (duh). But the first call gets all the way to sending the API command out and then yields while that happens asynchronously. Then the other setpoint is changed and does the same thing. EXCEPT, the original heating setpoint has not been updated in the hub because that process is not executed until the success of the API call. I know how basic this is to people but I'm something of a dinosaur and cannot get it through my pea-sized, dinosaur brain that things have to happen asynchronously because of the latency of internet communications. Ok....now I'm back on board with all of this and I must find some elegant solution to resolve this. Forgive me for showing my ignorance but I learned a valuable lesson (again, but maybe it will stick this time).
  4. When you drop any of the buttons on the designer and then select a button. On the right hand side you can chose the type Choose Type to be Button or Switch. When I make it a switch, I expect it to look like a ON/Off switch. But it still looks like a button. What is the purpose of this and how do you use it ?
  5. Czy ktoś może pomóc w wykonaniu QA? Potrzebne aby QA : - po naciśnięciu przycisku wykonało - "open" danego urządzenia - sprawdziło stan czujnika binarnego i zwróciło jego wartość w formie "otwarte" gdy true lub "zamknięte" gdy false - wpisało stan czujnika w etykiecie QA Przykład: function QuickApp:wjazd_open() -- nazwa przycisku QA hub.call(1955, "open") -- otwarcie bramy (smart implant zwiera styki) self:updateView("wjazd_label", "text", "Brama wjazdowa: " .. tostring(hub.getValue(152, "value")) ) -- 152 to czujnik otwarcia bramy end
  6. Whats the call to press a QAuickApp button from another QuickApp ?
  7. The EventRunner QuickApp makes it easy to write home automation rules, but also allows for development of very advanced rules Schedule actions at specific times with additional conditions Trigger actions when complex conditions are met Interact with other QuickApps and systems A complete event based programming language "eventscript" that is concise and powerful to describe concurrent automation rules. Example -- Setup some variables to use in rules (We could also use a "home-table") rule("xmas={ tree = 122, light = 166 }") -- xmas tree and light deviceIds rule("kitchen = {}") rule("kitchen.lamps = { 77, 98, 101 }"). -- deviceIds of lights in kitchen rule("kitchen.sensors = { 56, 33}") -- deviceIds of motion sensors in kitchen -- Define rules rule("kitchen.sensors:breached => kitchen.lamps:on") -- If any sensor is breached, turn on lights rule("trueFor(00:10,kitchen.sensors:safe) => kitchen.lamps:off") -- If all sensors are safe for 10 minutes, turn off lights rule("@sunset-01:00 & wday('sat-sun') => xmas.tree:on") -- 1 hour before sunsets on Saturday and Sunday turn on xmas tree rule("remote:key == '2:Pressed' => xmas.light:toggle") -- Key 2 on remote toggles xmas light on/off rule("kitchen.sensors:breached & once(06:00..08:00) => fibaro.call(RadioQA,'play')") -- Start radio when someone enters kitchen between 6 and 8, but only once Many more possibilities, with rules triggering on temperatures, alarm states, global variables etc etc... The rule language "event script" is designed to be reasonable easy to read. If condition before '=>' is true, then do the actions after the '=>'. If we don't have a '=>' it's just an expression that is computed, ex. for setting up variables like in the example. An beta of EventRunner5 is available now at https://github.com/jangabrielsson/EventRunner5 I will also publish versions available via the UpdaterQA which is probably the easiest way to install/update. Here is v1.03EventRunner5-1_03.fqa for download Many thanks to the bug hunters that helped me find problems @Sjakie @Neo Andersson @ChristianSogaard @Pica2017 @chelson @minsad79 Goals with EventRunner5 Backwards compatibility for rules from ER4 (as much as possible...) Better error messages Better debug possibilities Easier to extend with custom functions Some new cool scripting functions Much cleaner code - which will allow me to sleep better at nights... Current version is almost on feature parity with ER4. There are some bloat in ER4 I would like to skip unless people really need it... There are most likely bugs lurking in ER5 as it is not tested as much yet (However, I'm eating my own dogfood and have started to use it...) Introduction EventScript basics Variables EventScript in depth... Functions and properties Time scheduling rules - scheduling rules for time of day and dates Interval rules - rules running at given intervals during the day Trigger rules Event rules Alarm rules - arming/disarming and triggering on alarms Http and Nodered - integration with http requests and nodeRed flows Working with rules Settings and options Debugging and finding faults with rules... Terminal 5 - interactive web based terminal to play with rules on the HC3/ER5 Custom property functions - define your own :<property> functions Custom objects Advanced topics Recipes - common rules... Known changes from ER4: ER5 is not based on fibaroExtra so a lot of extra functions are not available. Especially functions defined for QuickApp. Ex. self:debugf etc. '=' has less priority than '&'. In ER4 we could write rule("@sunset => lamp:isOn & flag = true") which, if lamp was on set flag to true. In ER5 the priority makes this being interpreted as rule("@sunset => (lamp:isOn & flag) = true") which is not what we want and generates a runtime error. Instead, in cases like this, wrap the assignment in parenthesis rule("@sunset => lamp:isOn & (flag = true)") Alarms for partitions works differently Function to define rule is eval(...). They way eval is defined is differently. Most of this functions comes from the table 'er' that is passed to main(...). See declarations in the beginning of the main() function. A variable 'rule' is defined in the beginning of main(er) that points to the eval function so we can use rule("rule string") for backward compatibility... Nodered integration is slightly different. to be continued...
  8. Hi guys! I would like to say that I am a beginner on Fibaro. I would like to integrate my LED strip on HC3. I have the API Key, I downloaded the fqa file (from here https://marketplace.fibaro.com/items/govee-colorled-controller-qa) but I don't know how to proceed. I have created the Quick App, but I don't know what I have to do to configure it. Can anyone help me?
  9. Here is a link to a set of QAs to control Shelly devices. https://www.smarthome.com.au/free-shelly-quick-apps-for-fibaro-home-center-3/ It's both gen 1 and gen 2 devices. Gen 2 devices are easier to integrate with the web socket API than the gen 1 where we need to poll the device with regular interval. Battery operated devices are in general a pain to support as they sleep and wake up now and then - which makes polling difficult. So, battery devices are not in focus The QAs support the basic features expected from a device of that QA type so they fit into the fibaro model of handling devices. Extra features like setting timers etc that Shelly support is better handled with the pretty good mobile/cloud Shelly app. There are a lot of devices that are potentially supported but not all have been tested. Please give us feedback here or in https://www.smarthome.com.au/free-shelly-quick-apps-for-fibaro-home-center-3/ so we can come out with an 1.1 update... (gen 1 Shelly 1 and Shelly 1PM have issues but will be fixed in next release) The suite contains 5+1 different QAs that each support different Shelly devices. The devices tested, and devices not tested but we expect they could work are: ShellyMultiDevice v1.0 com.fibaro.deviceController + child devices Supported Shelly devices: - Shelly 3EM (Gen1). Note: untested Children: - com.fibaro.binarySwitch - com.fibaro.energyMeter - com.fibaro.energyMeter - com.fibaro.energyMeter - Shelly EM (Gen1). Note: tested Children: - com.fibaro.binarySwitch - com.fibaro.energyMeter - com.fibaro.energyMeter - Shelly Plus 2PM (Switch) (Gen2). Note: tested Children: - com.fibaro.binarySwitch - com.fibaro.binarySwitch - Shelly Pro 2 (Gen2). Note: untested Children: - com.fibaro.binarySwitch - com.fibaro.binarySwitch - Shelly Pro 2M (Switch) (Gen2). Note: tested Children: - com.fibaro.binarySwitch - com.fibaro.binarySwitch - Shelly Pro 3 (Gen2). Note: tested Children: - com.fibaro.binarySwitch - com.fibaro.binarySwitch - com.fibaro.binarySwitch - Shelly Pro 4PM (Gen2). Note: tested Children: - com.fibaro.binarySwitch - com.fibaro.binarySwitch - com.fibaro.binarySwitch - com.fibaro.binarySwitch Supported HC3 QuickAppMethods: - <com.fibaro.binarySwitch>:turnOn() - <com.fibaro.binarySwitch>:turnOff() - <com.fibaro.binarySwitch>:toggle() ShellySingleColor v1.0 com.fibaro.colorController Supported Shelly devices: - Shelly Color Bulb (Gen1). Note: tested, only color mode for now - Shelly RGBW2 Color (Gen1). Note: tested Supported HC3 QuickAppMethods: - QuickApp:turnOn() - QuickApp:turnOff() - QuickApp:setValue(val) - QuickApp:setColor(r,g,b,w) - QuickApp:startLevelIncrease() - QuickApp:startLevelDecrease() - QuickApp:stopLevelChange() ShellySingleCover v1.0 com.fibaro.rollerShutter Supported Shelly devices: - Shelly Plus 2PM (Cover) (Gen2). Note: tested - Shelly Pro 2M (Cover) (Gen2). Note: tested Supported HC3 QuickAppMethods: - QuickApp:open() - QuickApp:close() - QuickApp:stop() - QuickApp:setValue(value) ShellySingleDimmer v1.0 com.fibaro.multilevelSwitch Supported Shelly devices: - Shelly Dimmer 1 (Gen1). Note: tested - Shelly Dimmer 2 (Gen1). Note: tested - Shelly Vintage (Gen1). Note: tested Supported HC3 QuickAppMethods: - QuickApp:turnOn() - QuickApp:turnOff() - QuickApp:setValue(val) - QuickApp:startLevelIncrease() - QuickApp:startLevelDecrease() - QuickApp:stopLevelChange() ShellySingleSwitch v1.0 com.fibaro.binarySwitch Supported Shelly devices: - Shelly 1 (Gen1). Note: untested - Shelly 1L (Gen1). Note: untested - Shelly 1PM (Gen1). Note: tested, not working yet...TBD - Shelly Plus 1 (Gen2). Note: tested - Shelly Plus 1 PM (Gen2). Note: tested - Shelly Plus Plug IT (Gen2). Note: untested - Shelly Plus Plug S (Gen2). Note: tested - Shelly Plus Plug UK (Gen2). Note: untested - Shelly Plus Plug US (Gen2). Note: untested - Shelly Pro 1 (Gen2). Note: tested - Shelly Pro 1 PM (Gen2). Note: tested Supported HC3 QuickAppMethods: - QuickApp:turnOn() - QuickApp:turnOff() - QuickApp:toggle() ShellyPlusHT v1.0 com.fibaro.temperatureSensor + com.fibaro.humiditySensor child Supported Shelly devices: - Shelly Plus H&T (Gen2). Note: tested, experimental, only wakes up when new data is available Children: - com.fibaro.temperatureSensor - com.fibaro.humiditySensor Supported HC3 QuickAppMethods:
  10. So I have been working on integrating my ceiling fan & light into my HC3 hub. I want to treat the fan control as a device and the light control as a device. But the problem is that I need buttons and sliders for user interaction. I get that the focus is primarily on z-wave integration but it is very shortsighted to imagine that everything the user installs in his/her Smart Home will be z-wave enabled. Furthermore, it seems that Fibaro does not have much market share in the United States. Consequently we are left in the dust having to integrate our devices ourselves. The Fibaro tech support seems very non-responsive to its community of owners and simply patches bugs without sharing new and updated features. For example, I noticed there is a new thermostat UI that appeared recently. Or at least I did not see it before a certain recent FW update. I presume it was made available because Fibaro needed it to sell their own thermostat device. Truly, I love my hub. The use of a web interface is far superior to using a smart phone app, IMHO. And, if I cannot easily find a z-wave enabled device, I can create or help someone else create a device handler for this device. I use and enjoy my Alexa but home automation is far more than telling Alexa to turn on my lights. And why should I rely on an internet device for more sophisticated control strategies? Right now my z-wave continues to operate even when my ISP goes offline. My ceiling fan will rely on my WiFi operating but it does not have to go to the cloud to be controlled. Only my Nest Thermostat will lose connection to my hub when my internet goes offline. When the time (and money) comes, I will replace it with something z-wave or maybe WiFi but not cloud controlled. I think the biggest takeaway from this rant is that there needs to be a means to create custom UIs for child devices. An added bonus would be a few different control objects. Things like a select box, a multi-select box, a check box (or something that looks like a pushbutton?), ways to group things (a container) or a means to draw a line between sections. Granted that images may be memory hogs so adding a bunch of icons or other small pictures would be memory intensive but small icons that could be added to a global list in the device might mitigate some of that. It seems that many of these structures are integral to the HTML world and a part of the web client. We just need a way to safely use them in the UI. Also, a comprehensive list of Lua methods that we can use along with simple descriptions of their use. Fibaro relies too heavily on its community so leverage that community to learn and share their knowledge on use. Fibaro need not shy away from providing this list because they don't want to write extensive descriptions of each and every method. Reward your faithful users with better tools to take advantage of your systems and you may be rewarded with an increase in sales. You could think of it as hiring a huge team of unpaid integrators who develop creative ways to solve problems. I was impressed with one user who described his sophisticated solution to control his home energy use based on the hourly electric rates that his utility company makes available each day. We don't have that need in North America (yet) but I am aware of a niche market that could be tapped for remote locations who exist off-grid and use solar energy exclusively. Thank you for your time in reading this. I feel better having expressed myself even though I figure this will be ignored or looked at as impractical. Have a great day (or night). Peter
  11. Witam, szukam odpowiedzi na uważam dość szczegółowe pytanie dotyczące QuickApp. Otóż postawiłem sobie cel by z pomocą QuickApp "Termostat auto" zrobić sterowanie prędkością wentylatora od klimatyzacji. W termostacie MCO Home MH8-FC spotkałem się z czymś takim że ma on taką wbudowaną opcję w interface służącą do tego, dodatkowo ma też sekcję pokazującą w jaki jest stan jego pracy, wygląda to tak: Zależy mi na tym żeby stworzyć QuickApp, który też będzie miał te dwie sekcje, chodzi o to żeby nie tworzyć tego ręcznie za pomocą kontrolek i etykiet.
  12. This setup is designed for QA development using Visual Studio Code (VSCode). It includes an emulator, allowing you to run and debug QAs directly in VSCode. This setup is compatible with HC3, offering features such as code completion, syntax highlighting, and workflow tasks for downloading, editing, packaging, and uploading QAs to/from HC3. Tested on Windows 11 and MacOS, this setup should also work on Linux. You can download the repository from here. Documentation, still in progress, is available here. Additionally, there's a video tutorial on installing this setup on Windows 11. The setup in VSCode looks as shown in the image. This configuration allows you to develop and run a QuickApp (QA) offline on your PC, Mac, or Linux system, and interact with the HC3 in a controlled manner. There's also a simple Web user interface for interacting with the QAs and monitoring events (available at http://127.0.0.1:5004/frontend) To get started: Install Python 3 on your machine. NOTE! Only Python v3.11 is supported currently (3.12 will come later). To test if the installation is ok , in the vscode terminal window, type >python3 ...and see if it starts the interpreter. Install the required Python libraries from requirements.txt using >pip install -r requirements.txt. Create a config.json file with credentials to access the HC3, based on the config.json.example. Install the VSCode extension "Local Lua Debugger" by Tom Blind. Create a QA file in the directory, choose the launcher "Fibenv QA file (remote)," and start debugging with F5. For more examples, refer to the files in the examples/ directory. The included .gitignore file excludes the ./dev and ./test subdirectories, allowing you to test your own code without affecting the rest of the repository. For installing Python libraries, it's recommended to create a virtual environment in the folder first. This setup includes a Python wrapper for the Lua runtime (Lupa), addressing dependencies on luasocket and others, eliminating the need for Lua installation on your machine. To instruct the emulator about the type of QA, directives similar to TQAE can be used in the QA file, but with slight differences, as shown in the example. Ex. --%%name=MyQA --%%type=com.fibaro.binarySwitch --%%file=qa3_1.lua,extra; --%%remote=devices:788,790 --%%remote=globalVariables:myVar,anotherVar --%%debug=libraryfiles:false,userfilefiles:false function QuickApp:onInit() self:debug(self.name,self.type,self.id) fibaro.call(788,"turnOn") end Note the --%%remote directive It instructs the emulator that it's ok to call device 788,789 o the HC3. As a default, the emulator treats all resources as local (we can read from HC3 but then treat them as local copies) and we enable resources we want to interact with on the HC3 as 'remote'. This goes for other resources also like 'globalVariables'. The setup integrates with the Lua debugger, allowing for breakpoint setting and more. Note that this project is still in progress, and updates will be provided as improvements are made. The emulator UI can be accessed at http://127.0.0.1:5004/, with a Swagger page for implemented APIs at http://127.0.0.1:5004/docs. The port (5004) can be changed as needed. Supported APIs include various fibaro and net functions, along with api calls and plugin functions. The setup also includes classes for QuickApp development and management. Supported APIs fibaro.debug(tag,str) fibaro.warning(tag,str) fibaro.trace(tag,str) fibaro.error(tag,str) fibaro.call(deviceID, actionName, ...) fibaro.getType(deviceID) fibaro.getValue(deviceID, propertyName) fibaro.getName(deviceID) fibaro.get(deviceID,propertyName) fibaro.getGlobalVariable(varName) fibaro.setGlobalVariable(varName ,value) fibaro.getRoomName(roomID) fibaro.getRoomID(deviceID) fibaro.getRoomNameByDeviceID(deviceID) fibaro.getSectionID(deviceID) fibaro.getIds(devices) fibaro.getAllDeviceIds() fibaro.getDevicesID(filter) fibaro.scene(action, sceneIDs) fibaro.profile(profile_id, action) fibaro.callGroupAction(action,args) fibaro.alert(alert_type, user_ids, notification_content) fibaro.alarm(partition_id, action) fibaro.setTimeout(ms, func) fibaro.clearTimeout(ref) fibaro.setInterval(ms, func) fibaro.clearInterval(ref) fibaro.emitCustomEvent(name) fibaro.wakeUpDeadDevice(deviceID) fibaro.sleep(ms) ...and corresponding hub.* functions net.HTTPClient() net.TCPSocket() net.UDPSocket() net.WebSocketClient() net.WebSocketClientTLS() --mqtt.Client.connect(uri, options) --no yet --<mqttclient>:addEventListener(message,handler) --no yet --<mqttclient>:subscribe(topic, options) --no yet --<mqttclient>:unsubscribe(topics, options) --no yet --<mqttclient>:publish(topic, payload, options) --no yet --<mqttclient>::disconnect(options) --no yet api.get(call) api.put(call <, data>) api.post(call <, data>) api.delete(call <, data>) setTimeout(func, ms) clearTimeout(ref) setInterval(func, ms) clearInterval(ref) json.encode(expr) json.decode(string) plugin.mainDeviceId ---plugin.deleteDevice(deviceId) --not yet plugin.restart(deviceId) plugin.getProperty(id,prop) plugin.getChildDevices(id) plugin.createChildDevice(prop) class QuickAppBase class QuickApp class QuickAppChild class RefreshStateSubscriber class <name> property(get,set) QuickApp:onInit() -- called at startup if defined QuickApp - self:setVariable(name,value) QuickApp - self:getVariable(name) QuickApp - self:debug(...) QuickApp - self:trace(...) QuickApp - self:warning(...) QuickApp - self:error(...) QuickApp - self:updateView(elm,type,value) QuickApp - self:updateProperty(name,value) QuickApp - self:createChildDevice(props,device) QuickApp - self:removeChildDevice(id) QuickApp - self:initChildDevices(table) QuickApp - self:isTypeOf(typ) QuickApp - self:callAction(name, ...) QuickApp - self:setName(name) QuickApp - self:setEnabled(bool) QuickApp - self:setVisible(bool) getHierarchy() For your own QA development have the repo 'fibemu' downloaded in a separate directory. Then create your own vscode development directory, and initialise that as a git repo if you want. With that open, do File->Add Folder to Workspace, and add the fibemu folder. This is what Vscode calls a "multi-root" workspace and it. Create a lua (QuickApp file) in your directory. First line in your QuickApp file should be the offset to your directory --%%root=../<name of your dir>/ So if you have a multi-root workspace now that looks like o fibemu o myDirectory You set the root to ../myDirectory/ Then press F5 to start to debug. The launch commands and other will be taken from the fibemu folder. This way you can pull down new version of fibemu without messing up your own directory and development. Also, don't forget to setup your config.json with credentials (copy from fibemu/config.json.example) Here is a link to the multi-project setup instructions (may include a video in the future) Implementation Some implementation notes. Supported REST APIs. Workflow There are some defined vscode Tasks that help in remotely uploading and updating the QA on the HC3 from within the vscode environment "QA, download fqa" downloads an QA from the HC3 and saves it as a .fqa file. The task will prompt for deviceID and path where to store. The path/dir needs to exist "QA, download and unpack" downloads an QA from the HC3 and saves all QA files as .lua files. It also adds fibemu headers in the main file so it can be opened and run with the emulator . The task will prompt for deviceId and path where to store. The path/dir needs to exist "QA, upload" will upload the QA to the HC3. It will prompt for QA file. If '.' is given as argument it will upload the current opened file. This will create a new QA, with a new deviceId on the HC3. "QA, update" will try to update QA files, viewLayout, uiCallbacks, and quickAppVariables of an existing QA on the HC3. If '.' is given as argument the file must have set the fibemu header --%%id=<ID> so it knows what QA to update. One can also give the deviceId of the QA on the HC3 that should be updated. This is convenient when developing and avoiding new IDs being "consumed". Sometimes when you update a QA you would not like to update the quickAppVariables. In that case give '-' instead '.' for the current opened file, or -deviceId for an exiting QA on the HC3. Scripts An advantage with the emulator is that we have access to more lua functions than on the HC3 which allow us to write some maintenance scripts QA backup. Backs up QAs from the HC3 to a local directory, keeping the 3 last versions QA distribution. Packs a development file to a .fqa, initialises some quickAppVariables, adds readme.txt file and zips it to an archive. Known issues While the QA is running, break-points can't be added. This is a limitation of the debugger used. Just add the break-point and restart the QA. When the emulator crashes, it may leave a process open that keeps the port 5004 in use. The emulator will complain at restart that the port is already bound. You may need to manually kill the process. On Mac: >kill -9 $(lsof -ti:5004)
  13. This QuickApp gets extra information from your SolarEdge managed Solar Panels to give you the most insight of your SolarEdge installation. Site Details: Site details, such as name, location, status, etc. Site Overview: Site overview data. Inventory: Inventory of SolarEdge equipment in the site, including inverters/SMIs, batteries, meters, gateways and sensors. Inverter Technical Data: Return specific inverter data for a given timeframe. Site Power: Site power measurements in 15 minutes resolution. Site Energy: Site energy measurements in 15 minutes resolution. Site Environmental Benefits: All environmental benefits based on site energy production: CO2 emissions saved, equivalent trees planted, and light bulbs powered for a day. Use of the monitoring server API is subject to a query limit of 300 requests for a specific account token and a parallel query limit of 300 requests for each specific site ID from the same source IP. The monitoring server API allows up to 3 concurrent API calls from the same source IP. Any additional concurrent calls will return HTTP 429 error – too many requests. See API documentation on https://www.solaredge.com/sites/default/files/se_monitoring_api.pdf Site Details: id – the siteID name – the site name account id – the account this site belongs to status – the site status (see Site Status on page 53) peak power – site peak power currency - e.g. EUR installationDate – site installation date (format: yyyy-MM-DD hh:mm:ss ) ptoDate – permission to operate date notes type – site type location: country state city address secondary address zip time zone alertQuantity - number of open alerts in this site * alertSeverity – the highest alert severity in this site * publicSettings: isPublic - if this site is public (true or false) public name - name * Alert information is only available when using an API_KEY generated by an account. API_KEY generated at the site level does not return this information. Inventory: Inverter name – the inverter name e.g. Inverter 1 manufacturer – manufacturer name (SolarEdge) model name e.g. SE16K Firmware version e.g. 2.52.311 communicationMethod – the communication interface used to connect to server. e.g.: Ethernet or WIFI. serialNumber – the equipment serial number e.g.: 7F123456-00 connectedOptimizers – number of optimizers connected to the inverter Meters name – the inverter name e.g. “FeedInMeter” Manufacturer – e.g. “WattNode” Model – meter model number SN – serial number (if applicable) Type – metertype, e.g. “Production” Firmware Version (if applicable) Connected To – Name of SolarEdge device the meter is connected to connectedSolaredgeDeviceSN – serial number of the inverter/gateway the meter is connected to form – physical for a HW meter or virtual if calculated by arithmetic between other meters Sensors (Irradiance/wind/temperature sensors) connectedSolaredgeDeviceSN – the S/N of the device it is connected to e.g. 12345678-00 Id – e.g. “SensorDirectIrradiance” connectedTo – name of the device it is connected to e.g. “Gateway 1” Category – e.g.IRRADIANCE Type – e.g. “Plane of array irradiance” Gateways name – the inverter name e.g. Inverter 1 serialNumber – the equipment serialnumber e.g. 7F123456-00 Firmwareversion Batteries Name SerialNumber Manufacturer - the battery manufacturer name Model - the battery model name Nameplate capacity - the nameplate capacity of the battery as provided by the manufacturer Firmwareversion ConnectedTo – Name of SolarEdge device the battery is connected to connectedSolaredgeDeviceSN – serial number of the inverter/gateway the battery is connected to Interver Technical data: timestamp AC current (divided per phase) AC voltage (divided per phase) AC frequency (divided per phase) QRef (divided per phase) CosPhi (divided per phase) TotalActivePower apparentPower - Supported starting communication board version 2.474 activePower - Supported starting communication board version 2.474 reactivePower DC voltage groundFaultResistance powerLimit % Lifetime energy - Supported starting communication board version 2.474 totalEnergy temperature - Celsius inverterMode SLEEPING – night mode STARTING – pre-production MPPT – production THROTTLED – Forced power reduction SHUTTING_DOWN – Shutdown procedure FAULT – error mode STANDBY – maintenance LOCKED_STDBY – standby mode lock LOCKED_FIRE_FIGHTERS – firefighters lock mode LOCKED_FORCE_SHUTDOWN – forced shutdown from server LOCKED_COMM_TIMEOUT – communication timeout LOCKED_INV_TRIP – inverter self-lock trip LOCKED_INV_ARC_DETECTED – inverter self-lock on arc detection LOCKED_DG – inverter lock due to DG mode enable LOCKED_PHASE_BALANCER – inverter lock due to phase imbalance (1ph, Australia only) LOCKED_PRE_COMMISSIONING – inverter lock due to pre-commissioning LOCKED_INTERNAL – inverter lock due to an undisclosed internal reason operationMode 0 – On-grid 1 – Operating in off-grid mode using PV or battery 2 - Operating in off-grid mode with generator (e.g. diesel) is present apparentPower - VA (divided per phase) activePower - VA (divided per phase) reactivePower - VAR (divided per phase) cosPhi (divided per phase) vL1ToN - 1ph only vL2ToN - 1ph only vL1To2 - 3ph only vL2To3 - 3ph only vL3To1 - 3ph only Environmental Benefits: CO2 - quantity of CO2 emissions that would have been generated by an equivalent fossil fuel system SO2 - quantity of SO2 emissions that would have been generated by an equivalent fossil fuel system NOX - quantity of NOX emissions that would have been generated by an equivalent fossil fuel system treesPlanted - equivalent planting of new trees for reducing CO2 levels lightBulbs - number of light bulbs that could have been powered by the site for a day Site Power Detailed: timeUnit - the time unit (QUARTER_OF_AN_HOUR) unit - the measurement units (e.g. Watt) type - i.e. Production, Consumption, SelfConsumption, FeedIn (export) or Purchased (import) date - date and time value - power in Watt at that time of the day Site Energy Detailed: timeUnit - the time unit (QUARTER_OF_AN_HOUR) unit - the measurement units (e.g. Wh) type - i.e. Production, Consumption, SelfConsumption, FeedIn (export) or Purchased (import) date - date and time value - power in Wh at that time of the day Overview: id currentPower lastDayData energy lastDayData revenue lastMonthData energy lastMonthData revenue lastYearData energy lastYearData revenue lifeTimeData energy lifeTimeData revenue lastUpdateTime Changes version 0.1 (25th June 2023) - First (development) version Variables (mandatory and created automatically): - siteID = Site ID of your SolarEdge Inverter (see your Inverter Site Details) - apiKey = API key of your SolarEdge Inverter (contact your installer if you don't have one) - serialNumber = Short serialNumer of your SolarEdge Inverter (see your Inverter Inventory Details) - language = Preferred language (default = English (en)) - debugLevel = Number (1=some, 2=few, 3=all, 4=simulation mode) (default = 1) Download the QuickApp here (download the file and un-zip): https://github.com/GitHub4Eddy/solaredge_extra/archive/refs/tags/solaredge_extra-01.zip or from the Fibaro Marketplace: https://marketplace.fibaro.com/items/solaredge-extra How to install: Open the Configuration Interface Go to Settings > Devices Click + Choose Other Device Choose Upload File Choose file from your computer with .fqax
  14. What I normally do is to have a QuickApp for a particular function. For example Blinds_Controller, Gate_Controller or Bathroom_Controller. Where all the business logic is inside the QA. Then other scenes or users or Alexa just press the buttons in the QA to execute something. A few of the Logic examples in the Blinds Controller Will not open a blind in the Movie Room if someone is watching a movie. Will not close the blinds at night if there is a storm forecast, in case we lose power and cant activate them next morning Will not close blinds on Doors or Windows if they are open/ajar This way, I don't have to replicate the logic everywhere. BTW, there is an override button for the user, so they can bypass the restrictions if so desired. For some of the logic, it would be nice to know if a user pressed the button or a scene. I see this in the logs, but there is nothing there. Can I determine if a user or a scene pressed a button What is the "values":[null] in the event. [2023-06-05] [01:00:05] [TRACE] [QA-GATE]: UIEvent: {"eventType":"onReleased","values":[null],"elementName":"bnt_Lock","deviceId":1757}
  15. I made the mistake of buying the wrong model of the Nice Gate controller - it doesnt interface with Fibaro. It only has one input, the rest are coded. To make everything work I have cannibalized one remote and attached it to a raspberry pi with relays. This is working fine. But the QA on Yubii seems to crash when being used, and I have to go back and open the QA again. I suspect that I should be creating the HTTPClient class when required instead of creating it at startup. If so, I don't know how to free it when done. --[[Gate Controller Written by Rohit Gupta No copyright, use freely Versions 3.00 20230505 Created for HC3 --]] __TAG = 'GATE' local Lock = 0955 local Bool = {[false]='LOCKED', [true]='UNLOCKED'} GOpen = '/gate/open' GClose = '/gate/close' GPed = '/gate/pedestrian' -- These show messages conditional on flags and in colour in the Log function Error (Msg) end function Debug (Msg) end function Warning (Msg) end function Trace (Msg) end function Status (Msg) end function Device_State (Device) return fibaro.get (Device, 'value') end function Turn_Device_On (Device) fibaro.call (Device, "turnOn") end function Turn_Device_Off (Device) fibaro.call (Device, "turnOff") end function QuickApp.Show_Gate_Status (Msg) self:updateView ('lblStatus', 'text', Msg) end function QuickApp:Show_Lock_Status () local State = Device_State (Lock) self:updateView ('lbl_Lock', 'text', 'External Access = '..Bool[State]) end function QuickApp:Post (Param, Action) Status (Action) self.Http:request(self.Address..Param, { options = {data = 'text', method = 'POST'}, success = function(response) Update (Action) self.Posted = true Debug ('response:'..response.status) end, error = function(message) Show_Gate_Status (Action..' '..message) self:updateProperty ('value', Action == 'Open') Debug ('error:', message) end}) end function QuickApp:onOpen () Update_Gate_Status ('Opening') self:Post (GOpen, 'Open') end function QuickApp:onClose () Update_Gate_Status ('Closing') self:Post (GClose, 'Close') end function QuickApp:onPed () Update_Gate_Status ('Pedestrian') self:Post (GPed, 'Pedestrian') end function QuickApp:onLock () Turn_Device_On (Lock) self:Show_Lock_Status () end function QuickApp:onUnlock () Turn_Device_Off (Lock) self:Show_Lock_Status () end function QuickApp:onInit() Status ('Started') self.Address = self:getVariable("Address") Status (self.Address) self.Http = net.HTTPClient () self:Show_Lock_Status () end Lock/Unlock address a separate Fibaro relay that kills power to the Gate Controller. The interface has 5 buttons - Open, Close, Pedestrian, Lock and Unlock. And there is only one variable Address which is the ipaddress of the Pi. What have I stuffed up ?
  16. In the past I have used fibaro.sleep. As I am migrating from HC2 to HC3, I have started using setInterval. People seem to insist it is better, even though it destroys the readability of the code. I am finding that it doesn't always work. Sometimes it does not wait at all. Here Loop_Secs is 15, and it shows that in the log. Sometimes it works for two iterations and then just does not wait. At other times, it does not wait at all. While I was building it up and Main was empty, it was whizzing so fast, I could not get in from the browser and had to restart the HC. What am I missing ? function QuickApp:Loop () self:Main () Debug ('Waiting for '..Loop_Secs..' secs') setInterval (self:Loop(), Loop_Secs*1000) end
  17. I have seen somewhere in documentation a reference to some garage door openers. But when I look in swagger for the device in the /devices/hierarchy listing there is no entry. So my question is this, is there a mechanism to create a new device type? There probably isn't much to change and it could be built on an existing device type, I expect. I envision having four states (open, close, opening, closing) as well as an error state of some sort. I would also prefer to tell Alexa or Google Assistant or Siri to "Open the garage" not "Turn on the garage" but that may be asking a bit much, I fear. I will say that having taken the plunge into this adventure I am starting to understand things better. @jgab's TQAE has helped immensely. Thank you @jgab. Further, the tutorials that he has put on here are very helpful. I grow a bit frustrated that there are no "official" references for QAs and I haven't found a good way to find the relevant information quickly. Someday, when I grow up, I hope to be just like @jgab 😁 Thanks for any guidance on the above. PeterV959
  18. Hi Team, I try to develop some QuickApp on my HC3, but I have an problem with the http request : When I call an API (here switchbot api), the external API respond me an 403 error... The probleme isn't the API because the same request with an little php script works... I have tried much methods but I get only the response code 403. Recently, I have downloaded an quickapp on the marketplace. All review on it are good but for me, it's doesn't work. When I see the console logs, I can see the 403 error code from this downloaded QuickApp too. Do you have an idea for my problem ? You can find my function code here : function QuickApp:GetDeviceList() self.http = net.HTTPClient({timeout=10*1000}) local apikey = self:getVariable("apikey"); self:debug(apikey); --For debug an my token is successfuly loaded local address = "https://api.switch-bot.com/v1.0/devices" --local address = "http://10.0.10.10:1880/debug" self.http:request(address, { options = { headers = { ["Authorization"] = apikey, ["Content-Type"] = "application/json; charset=utf8", ["Accept"] = "application/json", ["User-agent"] = "Mozilla/5.0" --For try but no change }, checkCertificate = false, method = 'POST' }, success = function(response) self:debug(response.status); --return : 403 self:debug(response.data); --return: nothing self:debug(response.headers);--return: array self:debug(message); --return: nil end, }); end
  19. Hi, I currently have my hc3 setup with the quickapp p1 meter for house energy metering and made my own quickapp for metering the solarpanels. I used most of the code from the p1 quickapp to make sure it would work simply because I am not a coding wizard sadly :). I started running my quickapp and it worked like a charm, except for the energy panel aspect. I was producing megawatt houres of energy... The consumption also was acting up wierd at the same time. The child app resposible for reading the kwh data from the Growatt inverter is setup as an energyMeter like this: {name="Zon productie vandaag", className="ProductionToday", type="com.fibaro.energyMeter"} some more code of this child: class 'ProductionToday'(QuickAppChild) function ProductionToday:__init(device) QuickAppChild.__init(self, device) self:updateProperty("rateType", "production") end function ProductionToday:updateValue(devicedata) self:updateProperty("value", tonumber(devicedata.epvtotal)) --tonumber(devicedata.epvtotal) self:updateProperty("unit", "kWh") self:updateProperty("log", devicedata.update_timestamp) end When I noticed it starting to register megawatts I removed the line of code responsible for saving the data. self:updateProperty("storeEnergyData", true) While coding this quickapp I came across multiple "special" ways of fibaro to register certain types of data. My question now is, how does fibaro read this kwh data and process it?
  20. The Radiation Monitor collects radiation levels from all available stations around the world and shows 5 nearest stations to your location and one station with highest current readings and one station with the highest 24 hour average readings. The QuickApp uses the location (latitude and ongitude) of your Homecenter to measure the distance to the stations and to get the nearest stations. The bearings in degrees from your location to the stations is shown. Next to the measurements, the five nearest reactors are shown. The languages English, French, Polish and Duth are supported. Thanks to @Sankotronic for his work for his HC2 Virtual Device version and ideas. The main device shows the nearest measurement μSv/h. There are Child Devices for: Nearest sensor 24h average μSv/h 2nd, 3rd, 4th, 5th nearest sensor measurement with the 24 average in the log text Nearest maximum measurement Nearest maximum 24h average measurement The nearest five reactors are retrieved once at startup of the QuickApp or at the next interval if you click on the button. Radioactive@Home is a Polish science project using the distributed computing capabilities of the BOINC platform. The main goal of the project is to create a free and continuously updated map of radiation levels available for everyone, by gathering information about gamma radiation using sensors connected to the computers of volunteers willing to participate in the project. Project is completely non-commercial, participating will be free of charge (excluding cost of detector) and the software will be licensed under the GNU General Public License (GPL). μSv/h: The sievert (symbol: Sv) is a unit in the International System of Units (SI) intended to represent the stochastic health risk of ionizing radiation. In land navigation, a 'bearing' is ordinarily calculated in a clockwise direction starting from a reference direction of 0° and increasing to 359.9 degrees. Measured in this way, a bearing is referred to as an azimuth by the US Army but not by armies in other English speaking nations, which use the term bearing. The human population is continuously exposed to ionizing radiation from several natural sources (cosmic and terrestrial contributions). For most individuals, exposure to natural sources exceeds that from all man-made (artificial) sources combined. The man-made sources arise from peaceful (e.g. medical use, energy generation, and associated fuel cycle facilities, radioisotope production, waste management) and military purposes (nuclear tests and their fallout or radioactive release, nuclear explosions). Radiation levels: Green: Radiation up to 0.3 μSv/h Yellow: Radiation between 0.3 and 0.8 μSv/h Red: Radiation above 0.8 μSv/h 1.14 µSv/h - Shelter population 5.7 µSv/h - Evacuation of population 11.4 µSv/h - Issue Iodine tablets 0.114 µSv/h - Max daily dose == 1 mSv/year Reverse Geocoding by Nominatim Reverse geocoding generates an address from a latitude and longitude. The reverse geocoding API does not exactly compute the address for the coordinate it receives. It works by finding the closest suitable OSM object and returning its address information. This may occasionally lead to unexpected results. QuickApp code logics: onInit() Initialise the QuickApp getQuickAppVariables() Get all Quickapp Variables or create them createVariables() Setup the global variables setupChildDevices() -- Setup all child devices loadMap() Get the webpage from http://radioactiveathome.org/map/ (This is the main loop of the QuickApp) extractData() Extract the data from the webpage source-code geoDistance() Calculate the distance from the HC3 (QuickApp variables) lat/lon to the sensors lat/lon geoBearing() Calculate the bearing from the HC3 (QuickApp variables) lat/lon to the sensors lat/lon Check for the values to give the right dot colours for the sample and average measurements Store the values of all sensors in a table and sort the table on distance Run through the table to get the maximum sample and maximum average measurements. If there are more than one, get the one that is the nearest-by updateIcon() Set the icon (colour) based on the sensor measurement getCity() Get the cities and countries for the seven selected sensors from https://nominatim.openstreetmap.org/ and store them in a table updateLabels() Update the labels updateProperties() Update the properties updateChildDevices() Update the Child Devices Return to the main loop loadMap() Links: Radioactive@Home Map: http://radioactiveathome.org/map/ Status servers: http://radioactiveathome.org/boinc/server_status.php Reverse geocoding: https://nominatim.org/release-docs/latest/api/Reverse/ licence:Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright Nominatim Usage Policy (aka Geocoding Policy): https://operations.osmfoundation.org/policies/nominatim/ Variables (mandatory and created automatically): latitude = Latitude of your location (Default is the latitude of your HC3) longitude = Longitude of your location (Default is the longitude of your HC3) language = Preferred language (default = en) (supported languages are English (en), French (fr), Polish (pl), Croatian (hr) and Dutch (nl)) interval = Interval in seconds to get the data from the Radioactive@Home website debugLevel = Number (1=some, 2=few, 3=most, 4=all) (default = 1, debugLevel 4 is only recommended for solving difficult issues) icon_refresh = User defined icon number for refresh status icon_green = User defined icon number for values less than 0.3 μSv/h icon_yellow = User defined icon number for values between 0.3 and 0.8 μSv/h icon_red = User defined icon number for values greater than 0.8 μSv/h icon_error = User defined icon number in case of an error gettng the data Version 1.4 (6th February 2024) Added extra check for an empty response in the address from Geocity (thanks to @Sankotronic from the Fibaro forum) Version 1.3 (17th July 2023) Added extra check for the right response from Geocity (in case of response {"error":"Unable to geocode"}) Version 1.2 (11th January 2023) Added support for Croatian language thanks to @Sankotronic Version 1.1 (9th January 2023) Changed handling of negative values for dots and icons: if tonumber(num) >= 0 and tonumber(num) <= 0.3 then Added a better translation for French (thanks to @fredokl) Version 1.0 (5th November 2022) Added the nearest five reactors to the labels with distance and bearing Added a button to refresh the list of (five nearest) reactors Added a warning at startup if the latitude or longitude differs from the setup of your HC3 Replaced the creation of the dots 🟢🟡🔴 to the labels, so no longer for all sensors Added some extra notifications to the labels in case the website is down Extended the http timeout a bit, to give the reverse geocoding some more time to respond Added translations for new functions Version 0.5 (29th October 2022) Added translation to the Reverse API geocoding response (city and country) Changed calculation of the bearings only for the 7 selected sensors, not all sensors Optimized the code and added more structure by using multi file code (main, childs and i18n) Version 0.4 (22nd October 2022) Added six Child devices for the nearest sensor 24h average, 2nd, 3rd, 4th, 5th nearest sensor sample, the nearest sensor maximum sample and the nearest sensor maximum 24h average Added icons based on sensor measurements to all Child Devices Added translations for the labels and properties from English to French, Polish and Dutch. (Thanks to @ppeterr and @fredokl for help with the translation) Limited the details of the response of the Reverse Geocoding with zoom=10 (address detail = city) Version 0.3 (16th October 2022) Added the City and Country also for worst sample and worst average sensors Added all debug information and set the debug levels Optimised the code Version 0.2 (15th October 2022) Added the City and Country for all 5 sensors, not only the first one Version 0.1 (15th October 2022) Initial version Download the QuickApp here (download the file and un-zip): https://github.com/GitHub4Eddy/radiation_monitor/archive/refs/tags/radiation-monitor-14.zip or from the Fibaro Marketplace: https://marketplace.fibaro.com/items/radiation-monitor How to install: Open the Configuration Interface Go to Settings > Devices Click + Choose Other Device Choose Upload File Choose file from your computer with .fqa Icons thanks to @Sankotronic
  21. HomeWizard Wi-Fi Water Meter Quick App for HC3 The HomeWizard Water Meter gives you live insight into your water consumption. It reads your analog water meter. With the supplied adapter you can place the water meter on most existing Itron, Elster or Sensus analog water meters within 2 minutes. I got a lot of questions if I would create a Quick App for the HomeWizard Wi-Fi Water Meter. So I decided to build it, despite not owning the device. The Quick App reads the total and active water usage and it calculates the daily usage: Feel free to test and post your findings in this topic. Download You can download the beta Quick App v1.0b1 release from my GitHub repository (direct link to Wi-Fi_Water_Meter_v1.0b1.zip). If it's out of beta I'll upload it to the FIBARO Marketplace. You can download the Wi-Fi Water Meter from the FIBARO Marketplace.
  22. This is a Quickapp script for HC3. I am trying to get this to work in a VD on HC2. Is it possible, or do I have to do it together with a scene to make it work? Can anyone help? function QuickApp:onInit() self:updateProperty("unit", "kr/kWh") self.refresh = 60 -- in seconds local function loop() self:webrequest(); setTimeout(loop,self.refresh * 1000) end if self.username ~= "changeme" then loop() end end function QuickApp:webrequest() local tid = os.date("%R") local minutt = os.date("%M") --OPPDATERER STRØMPRIS OG SNITT HVER TIME if (minutt == "00") then self:OppdaterPris(); self:OppdaterSnitt(); end end function QuickApp:OppdaterPris() --Opprette lokale variable local GammelStrompris = fibaro.get(126,"value") local NyStrompris --Definerer http local http = net.HTTPClient(); --Definerer strengen Payload til å være kommando til tibber local payload = '{"query": "{viewer {homes {currentSubscription{priceInfo{current{total}}}}}}", "variables": null, "operationName": null}'; --API.POST til Tibber-- http : request('https://api.tibber.com/v1-beta/gql', { options = { method = "POST", headers = { ['Authorization'] = '.........', --Min Tibber ID her. ['Content-Type'] = 'application/json' }, data = payload -- Query. }, success = function(response) --fibaro.debug (response.data) --Verifiser at en har fått response.data. Dette er data som en har fått fra Tibber local data = json.decode(response.data); --fjernet local under??? NyStrompris = json.encode(data.data.viewer.homes[1].currentSubscription.priceInfo.current.total); self:updateProperty("value", tonumber(NyStrompris)) --print("OK") end, error = function(err) fibaro.debug ("Error:" .. err) end }); end function QuickApp:OppdaterSnitt() --Definerer http local http = net.HTTPClient(); --Definerer strengen average til å være kommando til tibber local average = '{"query": "{viewer {homes {currentSubscription{priceRating{daily{entries{total}}}}}}}", "variables": null, "operationName": null}'; --API.POST Til Tibber http : request ('https://api.tibber.com/v1-beta/gql', { options = { method = "POST", headers = { ['Authorization'] = '...............', --Min Tibber ID her. ['Content-Type'] = 'application/json' }, data = average -- Query }, success = function(response) --fibaro.debug(response.data) --Verifiser at en har fått response.data. Dette er data som en har fått fra Tibber local data = json.decode(response.data); local Nypris = tostring(json.encode(data.data.viewer.homes[1].currentSubscription.priceRating.daily.entries[31].total)); self:updateProperty("log", tostring(Nypris)) end, } ) end
  23. I recently switched from the HC2 to the HC3. I am using the Eventrunner4 Quickapp with complete satisfaction! The HC3 has the ability to create profiles. I would like to know the best method to turn a Quickapp on/off for a certain profile. Or is this already built into Eventrunner4? I can't figure it out.
  24. Hi @m.roszak Is there any update for providing Encryption of Quick Apps? Fibaro have the marketplace All over the wold a marketplace is a place where people buy and sell stuff - but neither is possible at Fibaro Marketplace. In my opinion Fibaro forces professional programmers to share their work for free, with no way to protect their work. I am not a programmer myself, so i pay for other people's work or get it for free from those that grateful provide that. I have paid for the following QA Irobot Roomba, Home connect, Hikvision NVR, Text to speak TTS - and they amazing guys who did those can only beg that people will donate if they choose to share them public. So if the donations is the only way to go, is this ok with Fibaro guidelines posting it at the "Marketplace" with a beg for donations??? I spoke with Roth Nordic and other companies, and they will not provide API information to their systems, if its not possible to protect the API commands. So with Fibaro's missing strategy for protecting QA is blocking for a lot integrations. When do you provide Encryption / remove Edit function of Quick Apps? To anyone else - dont ask me for the QAs - ask Fibaro for a way protecting QA, and I predict they will come soon after. Irobot Boomba HIKVision - creating a binary sensors for all enabled SmartEvents in Hikvision NVR Siemens Home Connect using Bearer token
  25. This QuickApp gets your energy consumption and production data from Tibber Live. This QuickApp can be used in combination with the Tibber Monitor to get the Tibber Prices. Based on the Fibaro WebSockets/GraphQL demo by Peter Gebruers If you use Tibber for your Energy Panel, you can use this Tibber Live QuickApp for your energy consumption and production combined with the Tibber Monitor QuickApp to provide the Energy Panel with the hourly prices. Main device with positive or negative actual power consumption Child devices are available for: power (Actual consumption with maxPower in log text) powerProduction (Actual production with maxPowerProduction in log text) accumulatedConsumption (Todays consumption, also the child device for the Energy Panel) accumulatedProduction (Todays production) accumulatedCost (Todays cost) accumulatedConsumptionLastHour (Consumed since since last hour shift) accumulatedProductionLastHour (Produced since last hour shift) lastMeterConsumption (Total consumption) lastMeterProduction (Total production) voltagePhase1 voltagePhase2 voltagePhase3 currentL1 currentL2 currentL3 Available information: power (Consumption at the moment (Watt)) maxPower (Peak consumption since midnight (Watt)) powerProduction (Net production (A-) at the moment (Watt)) maxPowerProduction (Max net production since midnight (Watt)) accumulatedConsumption (kWh consumed since midnight) accumulatedProduction (net kWh produced since midnight) accumulatedCost (Accumulated cost since midnight; requires active Tibber power deal) currency (Currency of displayed cost; requires active Tibber power deal) lastMeterConsumption (Last meter active import register state (kWh)) lastMeterProduction (Last meter active export register state (kWh)) voltagePhase1 (Voltage on phase 1) * voltagePhase2 (Voltage on phase 2) * voltagePhase3 (Voltage on phase 3) * currentL1 (Current on L1) * currentL2 (Current on L2) * currentL3 (Current on L3) * accumulatedConsumptionLastHour (kWh consumed since since last hour shift) accumulatedProductionLastHour (net kWh produced since last hour shift) accumulatedReward (Accumulated reward since midnight; requires active Tibber power deal) minPower (Min consumption since midnight (Watt)) averagePower (Average consumption since midnight (Watt)) powerReactive (Reactive consumption (Q+) at the moment (kVAr)) * powerProductionReactive (Net reactive production (Q-) at the moment (kVAr)) * minPowerProduction (Min net production since midnight (Watt)) maxPowerProduction (Max net production since midnight (Watt)) powerFactor (Power factor (active power / apparent power)) * signalStrength (Device signal strength (Pulse - dB; Watty - percent)) * timestamp (Timestamp when usage occurred) * on Kaifa and Aidon meters the value is not part of every HAN data frame therefore the value is null at timestamps with second value other than 0, 10, 20, 30, 40, 50. There can be other deviations based on concrete meter firmware. In this QuickApp "null" values are replaced by their previous values. To communicate with the API you need to acquire a OAuth access token and pass this along with every request passed to the server. A Personal Access Token give you access to your data and your data only. This is ideal for DIY people that want to leverage the Tibber platform to extend the smartness of their home. Such a token can be acquired here: https://developer.tibber.com When creating your access token or OAuth client you’ll be asked which scopes you want the access token to be associated with. These scopes tells the API which data and operations the client is allowed to perform on the user’s behalf. The scopes your app requires depend on the type of data it is trying to request. If you for example need access to user information you add the USER scope. If information about the user's homes is needed you add the appropriate HOME scopes. If you have more than one home in your subscription, you need to fill in your home number the change between your homes. If the Tibber server disconnects the webSocket, the QuickApp wil do a re-connect for the amount in the QuickApp variable reconnect. If the re-connect fails for that amount, there will be a timeout for the seconds in the QuickApp variable timeout. Use this QuickApp at your own risk. You are responsible for ensuring that the information provided via this QuickApp do not contain errors. Tibber is a registered trademark being the property of TIBBER. TIBBER reserves all rights to the registered trademarks. Information which is published on TIBBER’s websites belongs to TIBBER or is used with the permission of the rights holder. Making of copies, presentations, distribution, display or any other transfer of the information on the website to the public is, except for strictly private use, prohibited unless done with the consent of TIBBER. Published material on dedicated TIBBER press websites, intended for public use, is exempt from the consent requirement. Also see: https://tibber.com/en/legal-notice Guide Communicating with the Tibber API: https://developer.tibber.com/docs/guides/calling-api Tibber API Explorer: https://developer.tibber.com/explorer Tibber gitHub: https://github.com/tibber Tibber SDK NET: https://github.com/tibber/Tibber.SDK.NET/tree/master/src/Tibber.Sdk Fibaro webSocket manual: https://manuals.fibaro.com/knowledge-base-browse/hc3-quick-apps-websocket-client/ Fibaro Forum - Headers in webSocket: https://forum.fibaro.com/topic/60307-added-support-for-headers-in-websocket-connections-any-documentation WebSocket++ Documentation: https://docs.websocketpp.org GraphQL over WebSocket Protocol: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md GraphQL query language: https://spec.graphql.org/June2018/#sec-Language Version 3.0 (8th March 2023) Removed Tibber old Websocket code Prepared, not enabled: Check home.features.realTimeConsumptionEnabled has a true value always before reconnecting Prepared, not enabled: Added button to disconnect or re-connect the Tibber webSocket Prepared: Added quickapp variable homeNr (most of the time 1) to be able to check the response realTimeConsumptionEnabled Version 2.3 (beta 8th December 2022) Improved the 60 seconds interval child devices update, it now never skips a beat Added translation for English (en), Dutch (nl), Swedish (se), Norwegian (no) Changed the json response for the debugLevel=4 Offline Simulation mode, the date/time format was wrong Added random (jitter) reconnection handleDisconnected and handleError between 10 and 15 seconds Added random (jitter) reconnection interval handleDisconnected and handleError plus between 1 and 10 seconds Added exponential backoff (increasing delay) between each timeout. The increase is limited to 10 times the value in the quickapp reconnect variable. Version 2.2 (20th November 2022) Changed to new Tibber webSocket requirements, required from December 2022 Version 2.1 (15th October 2022) Child devices are now updated every (whole) minute to reduce CPU load Replaced zero values for Voltage L1 L2 L3 with the previous value Version 2.0 (5th August 2022) Added two child devices, Hourly Consumption and Hourly Production Added re-connect routine to handleError. If an Tibber error occurs, the QuickApp will try to re-connect. Thanks @JcBorgs for testing. Improved routine to handle Tibber null values. Thanks @Darquan for testing. Changed labels a bit to save some space Changed "volt" and "amp" text in the labels. Thanks @Morten22 for mentioning. Changed kWh device types from com.fibaro.electricMeter to com.fibaro.energyMeter Version 1.0 (19th June 2022) Initial webSocket version Tibber Live Thanks @JcBorgs for testing all beta versions and great suggestion to improve the quickapp Based on the Fibaro WebSockets/GraphQL demo by @petergebruers Variables (mandatory and created automatically): token = Authorization token (see the Tibber website: https://developer.tibber.com) homeId = Tibber Home ID (see the Tibber website: https://developer.tibber.com) homeNr = Tibber home (nodes) number if you have more than one home (default = 1) language = Preferred language (default = en) (supported languages are English (en), Swedisch (se), Norwegian (no) and Dutch (nl)) reconnect = Amount of re-connects after disconnect from Tibber server (default = 10) timeout = Pause after maximum amount of re-connects (default = 300 seconds) debugLevel = Number (1=some, 2=few, 3=all, 4=Offline Simulation Mode, 5=Live Test Mode) (default = 1) Fibaro Firmware: Minimal version 5.111.48 (beta) Download the QuickApp here (download the file and un-zip): https://github.com/GitHub4Eddy/tibber_live/archive/refs/tags/tibber-live-30.zip or from the Fibaro Marketplace: https://marketplace.fibaro.com/items/tibber-live How to install: Open the Configuration Interface Go to Settings > Devices Click + Choose Other Device Choose Upload File Choose file from your computer with .fqa
×
×
  • Create New...