Another new to Hubitat and having regrets

Or home assistant. Even though all my "z" devices are on hubitat, and all my logic in node-red, all my dashboards are on Home Assistant.

1 Like

Preface: Nothing I say is to discredit your experience. I don’t know whether Hubitat will be right for you or not. Could go either way.

You’ve bitten off an awful lot to chew. Migrating from one system that you’ve gotten used to, already have devices, have it set up how you want… to a new system you don’t know, that supports a different subset of devices, and approaches problems in different ways… it was never going to be easy.

At work we sometimes migrate companies from Google Drive to OneDrive or vice versa. How hard could it be? They’re both just file storage! Oh, the stories I could tell…

Anyway, I wish you luck. There are good people on here who will help you work through issues, or help you decide whether to stick with it or go back. Good luck!

8 Likes

That was going to be next suggestion, but honestly at this point I think this conversation is pretty much dead. The reality of it is unless the OP provides clear and complete requirements or one of us has ESP we won't be able to really answer his questions. I just wish the OP well on finding a solution that will meet his needs

4 Likes
  1. Of which around 16 was spent testing things from my long list of "does it do X" items. Plus the time spent reading the forum. Plus the time spent reading the documentation. All in all around 24 hours solid time over a week or so which I thought was reasonable.

This is the kind of comment that really turns me off a community. People who make assumptions and then criticise somebody based on those assumptions. There are several of these in this thread alone.

To re-iterate, I am testing functionality. I have a list of things to check and play with. For this, 24 hours is more than sufficient to make a "shall I spend the time migrating or not" decision.

Thank you, @waterboysh - that was helpful and illuminating. I take your point that the vast majority of timers can be implemented in other ways. I still have a few use cases that need an actual timer, but what you wrote is useful.

I know :slight_smile:

I haven't just jumped into it though - I know what functionality I need to duplicate, what functionality can change and I have lists of must-do, would-like-to-do and do on.

The responses show that people are assuming I'm trying to implement a live system when I've made it clear I'm testing functionality well in advance of switching over. The two questions I originally asked (dashboard and calendar scheduler) have both been answered (thank you to @garyjmilne, by the way - the Tasmota code is one of the reasons I was looking at Hubitat in the first place).

The other question I asked further down was to you, @mavrrick58 - since you said what I was doing was wrong, I asked you what is the best way to test rules, variables, timers, the dashboard and actions in the easiest way possible [but without using rules or timers]?

Apart from that, no ESP required. I have asked no questions that require more information and I certainly wouldn't presume to ask anybody on this forum to solve my problems for me when I'm only going to learn anything by being pointed in the right direction rather than being spoon-fed.

Sure, if you see I'm doing something inefficiently (and you absolutely understand exactly what I'm trying to achieve without making any assumptions about the size/complexity of my system), then tell me, but every single criticism above is based on false assumptions.

Nicholas.

Sorry if you took offence at the comment but as the information posted above was posted 16 hours ago you can see how I may have drawn this conclusion.

The simple truth is when you start a discussion/thread you get out of it related to what you put into it. You didn't explain fully what your ask was so people are responding as best as they can. Your assertion that this is all about testing is irrelevant since details are needed regardless. If you don't provide them people will try to fill the blanks to be helpful. The fact they don't know exactly what your list of items are you are trying to validate isn't on them but on you for not communicating it clearly. That is why I made the comment about needing ESP. You continue to complain about people making assumptions, but have yet to help them with details so they don't need to make assumptions.

This conversation would have gone very different from the very beginning if you communicated a few things in your very first post, but you didn't.

I mean honestly if you motioned in the very beginning that you had all of those services already running in your house from post #16 and wanted everything to run local on Hubitat I don't even think most folks would of said it was possible or even to continue. I know I wouldn't have. I probably would have immediately suggested you look at Home Assistant with a NUC type PC as a more viable option.

To specifically respond to your item you called me out on is simply that you didn't understand my point or read my comment. What I was explaining is that using time to trigger a action every x minutes is a very bad practice and should be avoided if possible. The example you provided looked like you were trying to schedule with a cron timer a job to run periodically. That is where that came from. That is all it was about and I didn't say anything about your method of testing in general. Though I did suggest you look at the other great built i apps to simplify automation setup for things that didn't need the power or RM.

This is impossible still because you haven't really provided anything of substance for requirements. So really you just don't want responses?

Good Luck on finding the solution for you.

To be fair, we all have different levels of experience articulating requirements to support or development teams, I don't think we can assume prior HA experience equals experience in those same aspects of professional IT practices....

3 Likes

Right and that goes both ways. We as advisors should be calm as we help the requester communicate their needs and they should continue to provide feedback as they find the gaps in the communication. I think the big problem here is that isn't going both ways.

That's true, probably unfair of me to call that out, you have been very diplomatic and constructive in that regard, only pointing out what you need. I should drop out of this conversation and leave these lofty ideals to my own topic.... :slight_smile:

Then perhaps the fault is mine. The questions I wanted answers to have been answered. What other information should I be providing?

Nicholas.

1 Like

A note on timers. I have a Control4 system as well as Hubitat. Control4 also uses explicit timers. Hubitat does not have explicit timer 'devices' built in. There are a few user contributed timers that one can find by searching in the community and/or on Hubitat Package Manager.

BUT one very likely doesn't need them. Users of all these automation systems have very similar use cases. There's a very high likelihood that whatever one is trying do has been done in the Hubitat environment without explicit timers. The people who regularly contribute here include experts on Rule Machine and Room Lighting (which does more than rooms and more than lighting). Those are 2 potentially complex apps that will do most of what most users are looking for.

None. I am glad you got all the answered you needed.

To hit a few points to hopefully help in all this.

The UI:

Beta testing:
Referring back to the whole "Hubitat is a pretty small company" means that they have to rely on user beta testing which is a relatively small group. You're free to enroll though, just shoot a message to @support_team to get enrolled.

The crutch here is that there are just too many variables in user environments to pick up everything in testing. The C-8 is unique, as was mentioned, because they deployed an overhauled ZigBee radio along with a mechanism to migrate ZigBee devices from one hub to a C-8. They do internal testing, do some "alpha" testing with select users, and then ran through beta. Get it to production and folks started having issues. The problem here is that folks have different approaches to implementing ZigBee, specifically with the device types used for repeaters. Much less for end devices. There's just too wide of a gamut of ZigBee devices and chipsets thanks to it's more open platform compared to Z-Wave. You end up with some really weird anomalies that they've been trying to work through.

Testing Functions:
I won't beat the dead horse about time based triggers. They can definitely be used, but putting something on a schedule that runs once a minute will probably result in a bad time (depending on what else you are doing with the rule). Working around this is typically quite simple, but it takes understanding the fundamentals of how things operate.

For something like Rule Machine, my go to is to create an actions list with no trigger. You can manually execute the actions using the "Run Actions" button after installing the rule. IIRC, the other built-in apps limit how they are run, so it's less of a concern.

Another thing to be aware of is virtual omnisensors which can take the place of most physical devices for trying things out.

Dashboards:
The in-built dashboard is really designed for single use. Meaning each tile is a one for one "capability" (like turning a switch on/off) or attribute (like current switch state). Like you found, there are custom drivers out there that this approach isn't really designed around. For something like a device with multiple switches, the typical approach is to create child devices (this is handled at the driver level). These show up under the main device but can function independently. So, you would add the individual children (if available) to your dashboard to manipulate them from there. If those aren't available for a custom driver, you can often drop a note to the developer to request they are created (I do think the Tasmota driver does this).

The names automatically populate based on the display name of the device from the device page. As mentioned, there are some custom local dashboard options out there that allow you to override the name. I use HD+ which was worth the setup time for me since I have tablets scattered throughout the house. It allows (like most others) to setup one dashboard config and to use it as a template for the other devices.

I'm not 100% sure, but there may be some options here with the default dashboard app with CSS customizations. [RELEASE] Simple CSS Editor

General Approach for Community Help:
As you've seen, threads can often get sidelined if there's too many things being discussed. My general recommendation would be to post a single thread for each issue. This helps with the thread staying on topic. I realize that puts more on the user's lap to have to create the various threads, but it goes a long way in helping you get your question answered.

The other piece is to try to provide your generic requirements. I think this was captured well here but goes back to the first point. Try to avoid the XY problem (e.g. posting saying "I want to drive rule execution from Google Calendar" when what you want is to run rules based on a dynamic schedule).

Hope all this helps!

4 Likes

Hopefully my CSS Editor can provide some assistance...,

This thread was basically "mildly cursed" from the moment the title was written. It has 2 parts:

  1. "new to Hubitat". To most readers, it implies both a newness to home automation, and an interest in learning and growing skills in Hubitat.
  2. "and having regrets". It's a statement of emotions, rather than needs or wants.

The reality is that the poster is not new to home automation, is still in the decision phase before a large migration, and has very specific but unspoken requirements.

I'm not criticizing the poster. It appears he did get the answers he sought, and so in a sense, the thread was a success. But since we're doing a little bit of post-mortem... :slight_smile: And I can tell we all had a few emotions working through it. That's what I mean by "mildly cursed". But I'm glad he got the answers he wanted.

7 Likes

Can you give us a list of make/models? A lot of them may not seem to work but do for a couple of reasons. You may have to switch to the generic driver and you have to click configure. Could be

Did you read the compatibility list? Some is If you have a bond hub you could potentially run them through that...

3 Likes

Hi Nicholas // @user5231

I opened this thread expecting to hate it, but I just wanted to chime in and say 'thanks' for remaining (what I'd see as) respectful throughout a potentially-touchy topic.

I'll stay out of the majority of this, because it seems much has already been covered.

But I would say that I agree completely with your comments on rule machine. I think most people agree that the UI is pretty much horrible. The power is there, people can accomplish virtually anything with it. But the UI / amount of clicks? Horrible. Ditto for the dash. I use a cloud based alternative.

So you're spot on with that part, in my opinion.

Anyhoo the reason for my comment is simply... Webcore.

Webcore is a built in app, runs local, and I would imagine, ticks all your boxes in relation to timers etc.

Not sure if I missed it, maybe you've already mentioned it, but.... Yeah..... Webcore. I use it exclusively and the power / UI is amazing in my opinion.

4 Likes

webCoRE is the reason that I moved to Hubitat when it was obvious that webCoRE would no longer be supported on SmartThings.

2 Likes

Same. That, and konnected.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.