Tutorial: Single scene instance / Event model

[jgab 2,642]

10 minutes ago, jompa68 said:

Please login or register to see this code.

json.decode missing

this one or another,? "node-red-contrib-better-sonos"

 

 

The decode is on the line after

Please login or register to see this code.

Yes, it's the better-sonos.

This is the flow

Please login or register to see this spoiler.

 

I have inserted a "unique msg" node that only sends the msg if the message have changed. That means we can send a sonosststatus/poll message every other second but only get a message back from node-red when any sonos status has changed. Saves some processing on the HC2 side.

Edited February 22, 2019 by jgab

[jgab 2,642]

18 minutes ago, jompa68 said:

Please login or register to see this code.

json.decode missing

this one or another,? "node-red-contrib-better-sonos"

 

 

However, it seems like the sonos node loses contact regularly with the sonos player. Maybe there is a better version.

4 hours ago, jompa68 said:

 

Added artist and Nickelback use case to the post

 

[petrkl12 228]

@jgab

 

in new version I have this error:

Error loading rules:Err:fibaro:get("448","TCPPort"), attempt to compare string with number

 

in row:

  fibaro.get=function(obj,id,...) 
    if id < 10000 then return fibaro._get(obj,id,...) else return fibaro._idMap[tonumber(id)].get(obj,id,...) end
  end
 

[jgab 2,642]

2 minutes ago, petrkl12 said:

@jgab

 

in new version I have this error:

Error loading rules:Err:fibaro:get("448","TCPPort"), attempt to compare string with number

 

in row:

  fibaro.get=function(obj,id,...) 
    if id < 10000 then return fibaro._get(obj,id,...) else return fibaro._idMap[tonumber(id)].get(obj,id,...) end
  end
 

Sorry, my fault. I pushed a new version that converts the IDs...

[jgab 2,642]

10 minutes ago, jgab said:

Sorry, my fault. I pushed a new version that converts the IDs...

 

It's interesting that some of the fibaro functions requires the deviceIDs  to be a number or they will throw an error, like fibaro:getName. However, fibaro:call converts the id with tonumber() and fibaro:get just merges the argument with other strings for an api.get call.

 

[petrkl12 228]

Thanks, now it works

 

I also need to increase timeout for http calls from 2000 to 10000. Could you please do it?

I have some errors in your hue support (Hue connection:"Bad file descriptor") and have tried it and it helps, thanks

[jgab 2,642]

3 minutes ago, petrkl12 said:

Thanks, now it works

 

I also need to increase timeout for http calls from 2000 to 10000. Could you please do it?

I have some errors in your hue support (Hue connection:"Bad file descriptor") and have tried it and it helps, thanks

Ok, pushed a new version. Set a global _HueTimeout in the beginning to whatever timeout value you need. If it's not set it defaults to 2000

[petrkl12 228]

Super, thanks

[petrkl12 228]

@jgab

 

It's really good new functions -  Event._registerID and publish/subscribe mechanism !

 

 

 

 

[jompa68 121]

How and what have you implemented with pub/sub?

[jgab 2,642]

Just now, jompa68 said:

How and what have you implemented with pub/sub?

At the moment it is only the iOSLocator that has that as an option.

I'm experimenting with other service scenes that will publish their results. Makes it easier to use them.

[petrkl12 228]

@jompa68

 

I will use it for my own hue support but in future there can be implement any VD support (NetAtmo, EvoHome, ...)

[petrkl12 228]

And also I have huge scene for detecting any movement in my house/floors/rooms (all motion detectors, switches, door/window sensors, CO2 growth ...) and via that i will be able to split it into more scenes.

[jgab 2,642]

Just now, petrkl12 said:

And also I have huge scene for detecting any movement in my house/floors/rooms (all motion detectors, switches, door/window sensors, CO2 growth ...) and via that i will be able to split it into more scenes.

Yes, I think that's a good use-case

[jgab 2,642]

2 hours ago, petrkl12 said:

 

It's really good new functions -  Event._registerID and publish/subscribe mechanism !

 

Just a note. publish/subscribe is the core of event models and I was really missing that feature between scenes.

Because we have it within scenes;

Event.event(<event>,<handler>) is a subscription for internal events that are published internally (Event.post(<event>)).

And we also have Event.postRemote(<id>,<event>) that posts an event into another scenes event loop - no matter if the other scene wants it or not.

 

Event.subscribe(<event>,<handler>)  is also a handler for events, but only for events from other scenes that are subscribed for.

Event.publish(<event>) sends event but only to scenes that have subscribed for them. We filter on the publishing side.

In theory, we could include Event.publish inside Event.post, but that would make Event.post slower and we may still want to send events to scenes that they haven't explicitly subscribed to.

 

So, publish/subscribe it should make it even easier to distribute logic across scenes. We don't need to know where the logic is (what scene ID) - just what events we can send and receive. 

Let me know if you use it and have ideas how to improve/tweak it.

[FrankT 0]

18 hours ago, jgab said:

Yes, it's default for iOSLocator and in main() for EvenetRunner.lua this is now an option

Please login or register to see this code.

This is for @jompa68 and me that have started to store our configuration data in a scene. Still works with fibaro globals.

 

@jgab what is the advantage storing data in a scene instead a global hometable? Both store date in SLC-memory, so I guess there is no faster reading or writing - a hometable has to be updated when a gobal variable changes but so has a scene. I understand that there must be an advantage because you are using it. 

 

/F

[jompa68 121]

A big advantage is that it does not get corrupt which can happen when you save variable in the traditional way

[jgab 2,642]

48 minutes ago, FrankT said:

@jgab what is the advantage storing data in a scene instead a global hometable? Both store date in SLC-memory, so I guess there is no faster reading or writing - a hometable has to be updated when a gobal variable changes but so has a scene. I understand that there must be an advantage because you are using it. 

 

/F

There are advantages and disadvantages.

Sometimes globals get reset when people use the variables panel. But that can of course be solved. 

The real advantage for me is that my configuration/hometable is handmade anyway and I can use scene editor as a quick "home table editor" and easily change values and have the formatting and visual layout that I prefer. I could of course run the scene then to update a global but why bother? 

The other drawback is that the syntax is json... but I'm starting to like that.

If you have a script that generate your home table it's different and a global may be simpler.

Globals are faster than reading the lua code from a scene - but this is just for startup data so it's not an issue in this case.

Edited February 23, 2019 by jgab

[jgab 2,642]

17 minutes ago, jgab said:

Globals are faster than reading the lua code from a scene - but this is just for startup data so it's not an issue in this case.

 

Trivia.

Reading a global takes ~2ms.

Reading a scene structure to extract the lua code takes ~70ms.

 

It's interesting because fibaro:countScenes() is implemented as

Please login or register to see this code.

and it takes ~70ms if called on another scene,  fibaro:countScenes(<other scene id>). That is expected because they fetch a scene structure like we do when we get the lua code.

However, fibaro:countScenes() on own scene (no arguments) takes ~4ms... so api.get is a clever function... Reading the lua code from the running scene also takes ~4ms, but we are not helped by that in this case...

 

[jompa68 121]

We arr talking about ms so not a big issie