What is your debug setup here? I don't get anything like your output.
I assume it is just a debug note set to entire msg, instead of only msg.payload (the default).
I tried that. Maybe it's the inject node that is configured to query?
Well - 2 different things here. He didn't show the flow with the mode node. He only showed the set mode node.
1st debug pic is the debug from a set mode node (pictured in the flow pic).
2nd debug pic is the debug from a mode node (not pictured in the flow pic).
So I did some testing, and over riding the modeId on the set mode node does not work for me either.
Flow:
Change node:
The response from the node looks like it works, but the actual mode doesn't change.
And confirmed on hub:
So for now @danfox52 just break the messages apart with a switch node and send the outputs to multiple set mode nodes, each pre-configured to the mode you want to switch to.
The only way I could get it to change was to do this:
with this Change Node:
I couldn't figure out how to do it using the actual name of the Mode.
So it appears we need modeName, not modeId. But that doesn't work.
I tried modeName, modename, and name. None of them worked.
I just mean that is how the set mode node should work.
Ok, the way Maker API works is that setting the mode is based on id and not name.
So it is probably correct as-is that you have to specify the id. (edit: It is, I just looked at the code)
A good PR or feature request for the node would be to have the node map name to id for you (basically a modeName as @danfox52 mentioned) before sending to the hub, so that the user can specify the name instead of id.
A second good PR may be to tweak the node info to be more explicit that the id is required, not name (even though the variable is called modeId... lol).
But for now, use the id.
1 Like
Exactly, you must set the Id, not the name
Yes there are some improvement that can be done, but at some cost
Here's options if we want to match name:
-
requesting all modes to do the mapping each time we want to set mode
- the flow will be slower
-
requesting and caching the mapping on node deployment
- but if you change the mode name, then you will be desync
-
I guess you can mix both, Cache + if the name doesn't match any result, then request all modes
- you have a problem if you switch two modes name ... but well ... it's really corner case
Text is easier than indexes, but in the end I'm not sure it is a big issue as long as it is clear/obvious that the input has to be an id and not a name.
Because it isn't clear now, even though the variable is "modeId", as you specify the mode name/text in the node settings drop down (see below), not id (even though it is id behind the scenes). So I would expect that most users would think that the over ride would be in the same format as what is specified in the node settings drop down.
I would tweak the node info text and move on for now. But that's just my vote. 
Or make it so it can't be overridden at all, and make users use specific nodes for specific modes. I would be completely fine with that path, too, as there simply aren't that many distinct modes on most hubs that using a 1-for-1 mode/node combination would be that burdensome. Users could always just stick the 4 or 5 set mode nodes on a single flow sheet, and just have other flows connect to them via link nodes...
So interested... are there people on here that had the progressive hub slowdown issues and have reduced RM rules instead implementing them using NodeRED, and that has now fixed these slowdowns ?
I don't use RM (well 2 rules) or have many Z devices and have four C4 hubs - none of which has slowdown issues, so trying to draw a perhaps long overdue conclusion.
Yup. In my case reducing the number of Motion Lighting and RM rules made a dramatic improvement in my hub interface speeds and response times on end device commands.
Maybe I had bad rules? Maybe I screwed up my Motion Lighting config? Don't know - I just know the end result.
That said, I removed a lot more apps after that, which also helped speed it up even more. No more HubConnect/custom data passing app, no of light mirror apps, no custom thermostat apps, etc. So my hub is 98% just zwave I/O at this point. Was zwave/zigbee, but I moved all zigbee to zigbee2mqtt last week.
Still have your MQTT app though. 
1 Like
That unfortunately blurs the conclusion..
beta 3 gets the app to where I always wanted it to be... few remaining feature gaps or new things to address - just bug fixes. You'll be happy with it I hope.
It dovetails very nicely with a NodeRED system for those wanting a 'system wide' control, status and data storage capability, like yourself.
It does, but I will say that I did it in phases. The largest benefit was the RM and Motion Lighting replacement. I chose to do the rest of the apps a few weeks later as I didn't see any reason to support apps both places.
I have to wonder what aspect of my four systems has avoided me ever experiencing slowdowns..... (although the upcoming v2.2.0 firmware shows that excessive events in any app - which my MQTT app can generate, if MQTT is busy, is not recommended going forward - beta 3 addresses this)
My suggestion is it's either C4 vs C5
Z-Wave or ZigBee mesh issues - or both - I have < 6 devices on each.
Rule Machine usage (I only have 2 rules)
Some other inbuilt OS management that I don't experience for some reason.
I use a lot of apps, both HE and 3rd party .. no issues
Node red has sped up my system after migrating RM to NR. But I was still experiencing a slow down after deploying changes, lasting a minute or two. Then I turned off logging on the MakerAPI app and the speed increase was amazing.
I am using NR on a Raspberry Pi4 with 4GB memory.
1 Like
Excessive logging is the devil. The storage on the hub just seems to be too slow to keep up sometimes.
It's too bad it can't buffer events in memory and then write them later. And if memory buffer fills - just start dropping events starting with the oldest. I would rather lose events than error out the hub or slow it down.
Maybe that is what it does already, and that still isn't enough. Only they know.
2 Likes
I don't know about avoiding the hub slowdowns. I just prefer the interface in creating flows in NR instead of Rules in RM. In NR, it's a lot easier to create, copy, and tweak. I have replaced almost all of my Rules and also created a couple of flows that work similar to community apps so I didn't have to learn Groovy.
Ultimately on the most basic level, the RPi is more powerful so, to me, it only makes sense that it would handle the logic of flows faster than Hubitat handles Rules. Unlike @JasonJoel, i have both my Zigbee & Zwave devices on HE and plan to keep them there. Both my meshes are operating without errors (knock on wood!) I have a couple of Aeotec Z-Wave Repeaters and 4 of the Ikea Zigbee ones.
AND, I am learning to get HE Dashboards like I like them. I do not like NR Dashboards except for their charting capabilities.
Overall, I am a HUGE fan of a Node Red/Hubitat combination to get the job done.
1 Like
