Make a fan use only OFF, Low, Medium, ON

If the Segmentation Adaptation Response(SAR) layer is used, there is a session ID there.
10.1.3.1.5 Session ID (4 bits)
This field identifies the session. The session ID shall be incremented when a new datagram
transmission is initiated. A receiver shall verify the session ID of all received segments. Segments
shall be discarded if an unknown session ID is detected.
So, it’s incremented.
For each message, and ACK is required. SAR is an option, it’s used to put together datagrams that are too big for one packet, and to allow network fairness. Since the ACK is a small message, the SAR may not be used. I couldn’t tell from my quick reading of the specification if its something that can be turned on and off as needed. If it’s always used, then it would go something like this:
Host sends command to change dimmer.
Slave sends ACK. From that ACK, we get a sessionID.
Slave eventually sends response to command. If that response sessionID is incremented from the previous ACK, then that’s the response we are looking for.

I was involved with ASTM for many years, and I would assume that other standards organizations are similar. If a need is not made known to the highest level, then it will never get considered. This is of course a multi-year process, and all we can do is document the need and be heard.

I think we as open source developers underestimate our influence. We are the ones driving early adoption of this technology, and I do believe we are in the infancy of home automation.

I don’t believe a smart home more complicated than a TV, some speakers and lights can be effectively automated using Alexa (for your average Joe). Eventually, yes. So, yeah, I think it’s us geeks incorporating complicated setups into our lives that will be listened to. Okay, off topic.

Of course, up to a point. If the Z-wave alliance approves nice shiny features, then I would assume the OpenHab Z-wave maintainers would at least make a determination on whether or not to implement.

Agree. In my original post, my mention of “core” meant, “not implemented in a rule”.

So are you volunteering to go to the 350+ technology and API providers that OH supports to have this added? What about all the folks who develop their own DIY devices? As an open source project with any corporate backing, the only things that get done are because someone volunteered to make it happen.

I personally am still not convinced that this idea is:

  • feasible for the vast majority of OH bindings in the first place
  • actually solves the problem any better than a Rule can
  • is worth the effort to solve in the proposed way.

Why not focus on the Z-wave binding first? Is this something that would require a rewrite of all bindings? I do like the idea of using the channel, so if your binding supports it, the rule won’t fail. But, there’s already oddities out there that will cause a rule to fail.
For example:
If a rule is triggered by a change, then you can use previousState in that rule.
If a rule is triggered by an update, then the implicit variable previousState does not exist, and will cause the rule to fail at run time.

Why would this be a bad thing?

Hmm, well, this is an interesting comment. I see a lot of discussion related to race conditions. It seems like that’s a pain point that should be addressed. Is this the best approach to solving the problem? I’m not sure. I’ve looked at the design patterns, and their use feels like something that’s required because of a deficiency somewhere else in the system.

Should we attempt to minimize frustration (posts in this forum) related to race conditions? If yes, then what’s the best way to do that? I don’t think what we currently have will reduce the problems end users are having with race conditions.

That’s a pretty big assumption - some bindings will have this visibility, but some won’t.

If I understand what you’re suggesting, this will likely never be implementable for ZWave. ZWave must retain backward compatibility, and such a fundamental change will break things. ZigBee does have a transaction ID, but depending on the device used to access the network, it will likely not be available as it’s a low level mechanism.

I’ve not really read through this thread, but I suspect that you’re trying to resolve an application level issue with a network level solution.

If you want it to be something that is universally supported by openHAB then yes, yes it does.

I didn’t say it’s a bad thing. I said I don’t see it as worth the significant amount of effort required. But I’m not a developer on bindings and my opinion doesn’t count for much. And you don’t have to convince me. You need to convince the maintainers and to do that you need to create an issue on github.

The vast majority of the race conditions you see discussions about would not be solved by this approach. Only this specific problem in the OP would be solved. And in my experience, there really are not that many discussions about race conditions like these compared to just about any other problem people have in OH. It’s simply not a problem that comes up that often.

If you really want to have the biggest impact on OH users, fix the race condition where rules start triggering before all the Items are loaded or their states are restored from persistence. Your approach would have zero impact on that though.

Got the sleep times down and everything still works . . .

500 = 200 after setting .now variables
1000 = 200 after postUpdate’s
2000 = 1500 after sendCommand’s

Best, Jay

Ok, I think I have this sorted out for me. I’m using a Dimmer item with a transform map file and a switch item in my sitemap.
I wanted to account for using the manual switch which could post any value from 0-100 and have it display the proper fan speed. I’m using a Honeywell (Jasco) Fan switch
items file:
Dimmer ToyRoomFan "ToyFan [MAP(fans.map):%s]" <fan> (Home, g3wayfan) { channel="zwave:device:41700d2a:node72:switch_dimmer" }

Sitemap line:
Switch item=ToyRoomFan icon="fan" mappings=[0="Off", 30="Low", 60="Med", 100="High"]
This gives us a quick and easy way to pick the speed and it also shows the current value if the switch was operated manually and the control number isn’t 0/30/60/100

And finally the fans.map file which just accounts for all values. Per the fan switch docs, you set your fan to high, then use the controller to adjust the speed. For my fan, the values 33 and 67 triggered a speed change, you may have to adjust within a few numbers for your own fan and switch.

Here’s the file, I didn’t quote the file as it didn’t keep them on their own lines. Just create a new file and paste in all the values. Adjust a bit for the names if you need to:

0=Off
1=Low
2=Low
3=Low
4=Low
5=Low
6=Low
7=Low
8=Low
9=Low
10=Low
11=Low
12=Low
13=Low
14=Low
15=Low
16=Low
17=Low
18=Low
19=Low
20=Low
21=Low
22=Low
23=Low
24=Low
25=Low
26=Low
27=Low
28=Low
29=Low
30=Low
31=Low
32=Low
33=Med
34=Med
35=Med
36=Med
37=Med
38=Med
39=Med
40=Med
41=Med
42=Med
43=Med
44=Med
45=Med
46=Med
47=Med
48=Med
49=Med
50=Med
51=Med
52=Med
53=Med
54=Med
55=Med
56=Med
57=Med
58=Med
59=Med
60=Med
61=Med
62=Med
63=Med
64=Med
65=Med
66=Med
67=High
68=High
69=High
70=High
71=High
72=High
73=High
74=High
75=High
76=High
77=High
78=High
79=High
80=High
81=High
82=High
83=High
84=High
85=High
86=High
87=High
88=High
89=High
90=High
91=High
92=High
93=High
94=High
95=High
96=High
97=High
98=High
99=High
100=High

Hope this helps someone else, it took me a bit to get it figured out and working well

~J

I haven’t followed this thread, but instead of creating a big long map file like that, you can use the Scale transform. That sure if translation from a team of values to a single value is what the Scale transform was made for.

1 Like

Ok thanks, I’ll look into that and post an update. I saw it after I had built the file, but wasn’t sure if it worked with a switch item set up like this.

Well I poked around for a bit but I couldn’t find any great info on how to do this with a scale. It seems you may then need another method or rule to account for the ranges etc. If anyone has some info, I’m happy to give it a try, but for now this works for what I need and the time of building that map file is behind me.

I wasn’t sure how to relate the sitemap line to have the fan speed vs the number show up. Here was my scale file:
[…0]=0
[1…32]=30
]33…66]=60
]67…100]=100

It seemed to work, but my sitemap mapping wasn’t triggering to reflect “Low”, “Med” or “High” it would just show the 0, 30, 60, 100.

~J

So far as I know, SCALE (like other transforms) actually outputs strings not pure numbers. As such, this style should work -
[..0]=Off
[1..32]=Low
etc.
Only two dots, though!! (three dots looks like a forum posting artefact)

The technique is successfully used by others to convert wind angle to compass points etc.

Sure enough, I should have tried that! The (limited) info I found on the scale files only had it going to a numeric value, then using some javascript or a rule to do a further conversion.
This works great and then the files would be easier to manipulate, thanks all!
here is fans.scale
[…0]=Off
[1…32]=Low
]33…66]=Med
]67…100]=High

and my item file entry now:
Dimmer ToyRoomFan "ToyFan [SCALE(fans.scale):%s]" <fan> (Home, g3wayfan) { channel="zwave:device:41700d2a:node72:switch_dimmer" }

The sitemap file is unchanged:
Switch item=ToyRoomFan icon="fan" mappings=[0="Off", 30="Low", 60="Med", 100="High"]

~J

2 Likes