This is actually correct. Websocket needs to be checked for HE to update nodes in realtime. I’m really not sure how this detail got left out of the docs, but ill make sure @april.brandt adds it to them when she gets off work today.
Good work catching that!
Phew. That’s a relief. 
I’m a real poke-and-hoper and I am always wary I create more issues than I solve.
Just want to mention one thing regarding websockets on HE, if you use authentication on HE and require a login to get to the UI, websockets will be available BEFORE login, but will never send data. It is important to connect to websockets AFTER login to receive data. Just a short notice on something which may cause issues. I’m sure there’s more info regarding this particular issue out there.
It is a little clunky, but I use global vars for virtual devices. The event firing if there is a change to that var is the hard thing to track. The only way I know it’s to link any change to the var to all the places you need an event fired.
It seems a fundamental need that Core has some ability ‘now’ to link (status/control) to an arbitrary MQTT topic for an MQTT exposed device that is not specifically using zwave | zigbee 2mqtt. So is a virtual device capability imminent?
At the moment Core really has no useable internal device concept, no status or control for devices, no concept of internal triggers No rules engine, no display or dashboard, no scheduler etc. essentially it is just a server with some preinstalled services for ZigBee and zwave and an MQTT server. That’s a pretty basic automation capability however in that remit Core does everything very nicely. Adding the next parts with an equivalent managed experience will be great. We are all rooting for this :-).
Now we are where we are and I know these things are all planned sometime but the project has already been fortunate due to some awful circumstances in having quite a bit of extra unexpected time already to work on the docs and software. It was initially ‘crowd’ launched a year ago…
So … I do worry about development resource going forward, particularly with Oh-La’s loss of some GUI skills. Until this evolves we (the user/developer/early adopters) do need some ability to work around such issues with some tools and basic features like virtual devices , some rudimentary form of API , NR Core nodes etc in the interim. Am I needing say a dashboard ?.. No not at all (yet) , for most things I can work with NR but I don’t want Core to just be a Zwave and ZigBee interface to an embedded MQTT server.
The increasing community references I keep seeing posted to leverage HE nodes and the HE controller itself positions Core as a peripheral to HE (a still required accessory) which is absolutely not a role that should be advocated.
This statement is not 100% correct. As I’m approaching a full work day, I don’t have enough time to respond properly, so I’ll wait until I am able. You’ve obviously taken a lot of time and thought to create this post. So, I’d like a chance to respond appropriately. I will do so later today.
The way I test stuff is to create inject nodes that have the test payload. I know it’s not exactly what you wanted but you can emulate events at your leisure. You can even schedule when the inject node triggers.
NR on the CORE comes with an “inject enhanced” node that has a lot of trigger options.
What should your virtual device do? Maybe the community here can help with your exact use case.
There are plenty of ways to implement a virtual device on CORE depending on what your use case is. There just isn’t a standard/internal way to do so at this point.
Options include but aren’t limited to
Using MQTT Topics to simulate a device manually
Using NR context/variables
Kevin,
Although I understand your points, I guess I’m curious as to why you would be posting this type of opinion about CORE as we’ve made it very clear that we are in a hardware beta. Your post either insinuates that you have blatantly ignored this information and expected more of this beta or you’ve posted this in an attempt to create some sort of drama in our community. I only say this as you posted a similar post elsewhere.
Our GUI is moving forward, and has been in development this entire time. Eli being absent, although felt is not the end of the world. You mention this in a way that makes it sound like there is no one able to fill his shoes. That is simply not true.
You refer to the references to leveraging HE, but you fail to mention that references are made to the other services available within CORE as well. This is exactly how CORE can/will be used. References are made at this time to allow beta users to experiment with their units.
We’re not asking people to abandon HE. We’re not even asking users to make a choice. Are you sure that you’re not referring to HE as a peripheral device? Generally, where you would place the main logic is not usually referred to as a peripheral device. As users, we were banned from HE early on. That being said it’s quite a stab to make these insinuations. Since we’ve been able to run all of our home automations directly on CORE without said environments, I’m a bit taken aback by these inferences. We will, however work very hard in continuing to make CORE an all-inclusive platform which, whether you like it or not, will include integrations with HE and other services/devices/hubs.
It does sadden me that you’ve had such a reaction towards this project when many users that have received their COREs have been pleasantly pleased with their experience. Even with the learning curve, many have reached out to us or have joined us in open meetings to discuss all that is CORE. Only now, I realize that you haven’t done any of that. You haven’t even extended us the courtesy of having this discussion with one of us about any of your concerns directly. We’re not unapproachable or unavailable. As a matter of fact, we’ve been available in open Teams meetings for the past two days and we’re very active in the community.
In closing Kevin, I’m sure happy we cleared the air on this. We’re here if you want to talk.
Well, I’m now somewhat taken aback too !
I was I guess trying to clarify the future positioning for Core so that it has the best chance of succeeding in this market. Why and what people would be choosing Core to achieve over other offerings, It’s current incarnation is quite different to the initial positioning that it appeared, to me, to have back then. However it’s an in progress project launched during the most challenging of times and so that is expected.
As you may know my own large HA system is very much MQTT centric and so Core seems ideal in this regard. I do not use ZigBee or ZWave very much as I feel they are problematic, almost every support post seems to revolve around the, but I am hoping Thread / Matter will chnage my view here on RF based integrations. I do extensively use IP based integrations. I had hoped to be able to include MQTT devices easily within Core and to even contribute code to your product similar to that I offer for HE with my HE MQTT integration application.
Well … that I actually find quite surpising that you aren’t interested in feedback as to what a user feels is needed to build a product that can survive in the market - I had perhaps misunderstood that this is currently a hardware beta as it is being built as an OEM offering on standard hardware. It is the overall product that people judge by.
Wow - I find the inference you make personal, insulting and unprofessional . I’m sure your community guidelines would typify this style of reply as inappropriate.
As I said above I am not really bothered by the GUI in the dashboard sense - in fact I am in the ‘dashboard being a minor part of a home automation implementation need’ camp as automation should be something that happens and not something you constantly have to intervene with. Having a GUI for the config of Core is going to be nice though. GUI’s help less capable users use get things right and expand sales into these users.
I mention HE frequently only because it crops up a lot, probably the most, in solution posts. HE in my opinion is also suffering from lack of company resource to innovate and move forward. Again in the GUI area inparticular although I do not see that as being a critical feature. HE does have API’s and an internal device model with virtuals that allow users to augment these features with device drivers. That is not the case on Core… but will be in time I hope.
I have not as far as I know ever referred to leveraging logic in HE for it’s peripheral function. You have NodeRED for that and I think that aspect is well reasoned albeit it adds quite a extra bit of undertanding and time to implementations. . Having the Core nodes would really streamline that.
Well, you are mistaken in that, I have attended and contributed in nearly all those.
… again mistaken but I can understand how that got lost amongst the significant other world issues you’ve had to contend with.
I was offering an opinion on a minimal feature set that I feel you need to get to to allow the users to assist you help the product evolve in the market whilst you work on the other more bespoke applications for things like scheduling, logic, GUI etc.
I hadn’t realised you only wanted hardware beta feedback at this stage - my mistake.
I offer the following as background just to illustrate that I have a lot of experience here . You will no doubt interpret it for my dramatic ego. I have been in this industry a long long time and have founded many companies from startup (3 employees) to a Times 250 $500m company with 4000+ employees. That later success allowed me to buy into your beta 
. I have product invested and launched many products and seen product casualties too that should not have happened and are still happening on an almost daily basis.
I really want Core to succeed , that’s why I am here. If you feel otherwise and that I am just provoking ‘drama’ then again you are mistaken
Some integrated virtual device capability I see as essential to this as well as some basic device API offering (or more practically the availability of Core nodes for node-RED) however temporary or unpolished. . The other custom applications I see as increasing useability of your product to the major audiences and hence sales. Enlisting users with some basic tools to assist you during this path and provide temporary workarounds is vital to permit expansion and adoption as you bring on board your own resources.
I think I need to await the stage when you are open to discussing software in a beta. Not the existing software persay but the overall direction and steps to get there. Yes, maybe I had expectations a little above what is there currently, akin with your initial campaign flavour. Not a lot but a few fundamentals.
As I have obviously rattled you by stepping outside of the typical adolation feedback I’ll put the cover back on my cage and just watch and see. I really do want Core to succeed (heavens I even offered to fund your entire initial berta build !) and I don’t want to antagonise you further so let me go into a watch and wait mode and see what happens.
I had hoped to be able to contribute more at this early stage - hence why I bought two hubs - one purposed for this development.
I too hope we can make up further down the road but for now a break seems appropriate as it serves no ongoing purpose as it rather surprisingly has not been interpreted as constructive but mischievous drama.
A temporary adieu … although hopefully just for the time being
Kevin
I do feel like I am interrupting two people having a much more meaningful discussion… Says the guy writing a lengthy response to an already lengthy conversation…
But I had also wondered, like the earlier posts in this topic, about how to translate my somewhat heavy use of virtual devices in HE to my setup in Core / Node RED. Aside from the broader “system design” aspects to this conundrum, I was considering more the ease of transition for existing HE users (or perhaps those on other platforms) to Core. I am also happy to wait until the internal rules options are available to see what they offer, but would push to see the inclusion of variables or similar be available as an equivalent to what people are comfortable with already. Node RED, for the very little experience I have, seems a steeper learning curve compared to what people are likely to be used to.
I just wanted to make a small point, but seem to be making a broader statement… 
Personally I hope this has just been a misunderstanding and “temporary” is very short period of time. We wouldn’t want to lose experienced Home Automation enthusiasts willing to put their money and time into seeing a project succeed, nor see anyone in this growing Community feel the need to opt out.
For my part I would suggest that the transition for customers from HE be as smooth as possible, which I am sure is top of the list, but hopefully this feature of HE is a large part of delivering on that outcome.
Nice I was just coming to see if something like this existed.
It does. In more than just home assistant. I’ll prioritize this. If someone has a specific use case, it would be helpful.
@april.brandt . As requested above.
All I’m after is a virtual device that I can assign a custom driver to.
I can then set the virtual device with the details of my RPi (IP address) and LWRF hub (IP address and room and device number) to.
The RPi then talks to my LWRF hub and does the necessary switching on/off/dimming.
I’m not sure if the CC system allows for custom drivers and will even work.
Already discussed this with Markus last evening. If I’m right, you’re using the pins on the rpi for this interface?
Actually I’m not. Just connects through my LAN.
If you want to touch base with Markus and I later, we can look at getting this on line for you. We just need a better understanding of how you’re using it and look at the possible ways of connecting. We can assume, but it’s never good to do that. We want to get this working in case others discover or need this functionality.
I’ve decided my last post was overly harsh and served little constructive purpose so I’ve deleted it.
I really do want Core to be the product to rule them all and as April pointed out there are big gaps in my project understandings, that as an outsider I’m not privy to, addressing how Oh-La are planning to achieve that and remain commercially viable.
So I’ll remain, fingers crossed and watch and wait and see how we get on. praying Core will evolve into the wonderful product we know it could be.
Kevin