Laatste onderwerp 26 u geleden

Two light switches for the same light. how to install relay swi… forum

forum.fibaro.com/topic/20359-two-light-switches-for-the-same-light-how-to-install-relay-switch

Invision Community-forum in het Engels. 1 rubrieken gevolgd: Other Devices / Third-party devices.

Discussies per dag
6
Opgehaalde discussies
149
Berichten per dag
7
Rubrieken
1
Gevolgde bronnen
2
Software
Invision Community

Laatste discussies

Elke 4 uur opgehaald uit de openbare feed van het forum. Alleen de titel, de link en het begin van het bericht worden weergegeven; elke link wijst terug naar de bron.

Clickable UI via HTML

Next demo, just few lines of code (+JavaScript, few lines). Interesting, isn't it? 20260922_162548.mp4

Clickable UI via HTML

@Łukasz997 , you are talking about a new feature in the legacy view component which is not anymore developed. I understand what you try to achieve so I will report this to our team for evaluation, keep in mind that it will be analised under the assumtion that this (or similiar) feature will be analisied for the new architecture and native views, not the old legacy ones. This will probably mean more custom defined views and behaviour in the new architecture. As soon there will be some comments from the development team I will let you know.

Clickable UI via HTML

This is what the interface could look like, with simple clickable links. It is still outdated, but it is still big step forward compared to a static interface (replaces five buttons). The only obstacle is that damn feedback (blocked here by Javascript). I would like to get Fibaro interested in this. I think it is worth looking into. Could I ask for your thoughts on this? 20260922_124735.mp4

Clickable UI via HTML

Calling a QuickApp function from an HTML link without opening a new tab A link pointing to the following endpoint can be placed in a QuickApp text field: /api/callAction?deviceID=ID&name=htmlClick Clicking it correctly executes the htmlClick() function in the QuickApp with the specified ID. This potentially offers some very interesting possibilities for creating clickable HTML interfaces. In the example below htmlClick() is executed as desired. The problem is that the browser displays the API response every time in new browser tab, additionally switching user to that tab. This makes it unusable... With target="_blank", a new active tab opens. A named target allows the same tab to be reused, but the browser also switches to it after every click. I tried iframe, object, onclick with fetch(), and ping. Fibaro either removes or blocks the required elements and events. The only working workaround I found was a Tampermonkey userscript that intercepts the click and performs the request using fetch(). Of course it will not work in phone app. I can post the script if anyone is interested. Below the QuickApp code with the clickable link below. My question is: Has anyone managed to trigger such an action without opening or switching pages, using only the HTML supported by the HC3 interface - without an external userscript or browser extension? function QuickApp:onInit() local url = "/api/callAction?deviceID=" .. self.id .. "&name=htmlClick" .. "#hc3-action" -- tag to filter out by user

FlowMan

I stripped FlowMan down to the minimum. I removed data validation and pcall-based error handling. I also added new loop function with a predefined number of iterations and an unlimited loop that can be terminated on command from within - something similar to break. The whole framework is now about 250 lines long. I then ran an experiment in two versions: a “raw” version written directly with asynchronous operations, and another using FlowMan. The task was to: retrieve a list of files from a public GitHub repository, display their names, download the contents of each file in sequence, display the downloaded data. The result was that the length of raw asynchronous code was similar to FlowMan version. Async still remain well readable. In my opinion FlowMan version is more clear - this is just sequential run, almost like above task description. To be honest - FlowMan is a functional and fairly elegant experiment. It didn't show an advantage in terms of code size, but it did demonstrate an advantage in flow readability - for someone who does not want to follow the callbacks. Probably can show more power with longer chains. I include new version + new tests in both versions. Tests was written by AI. FlowMan.lua GitHub_Raw_Async_Demo.lua GitHub_FlowMan_Demo.lua

FlowMan

MAIN LIMITATION. You cannot write: flow:call(...) print("this should happen later") flow:call(...) and expect the following order: call print call The print() instruction will execute while the Flow is being REGISTERED, not during its later execution. Therefore, ordinary code that is meant to be part of the process must be enclosed in: flow:step(function(ctx) ... end) This is a fundamental limitation of the framework.

FlowMan

I’ve recently been working quite a lot on a Fibaro licensing system which, among other things, communicates with GitHub. The whole process is asynchronous, so I had to find a way to deal with it. You never know when a response will arrive, and you cannot simply stop the program and wait for the result. A solution is the continuation-passing style (CPS), where the continuation of the program logic is passed to a callback and executed only after the previous asynchronous operation has finished. For me, keeping a larger program written this way under control is a nightmare. It will never be as easy as Python with async/await. But Lua on Fibaro does not even provide coroutines, which could make this programming model much simpler. That is why I created this small framework, which I called FlowMan. It allows a large part of the asynchronous machinery to be hidden - although, of course, the execution is still asynchronous - behind something that looks almost like linear program execution. Instead of manually building more and more nested callbacks, I simply describe the consecutive steps of the process. AsyncMan takes care of the execution order. If a step is synchronous, it moves on immediately. If it is asynchronous, it pauses that particular logical flow and starts the next step only after the callback reports that the current one has finished. The program as a whole, of course, keeps running all the time - nothing is blocked (no busy-loop-like). As a result, I can at least writ

149 discussies opgehaald sinds 1 September 2026. Volg dit forum op zoekwoord →