As per the title is this possible.
I couldn’t find anything in the documentation.
As a complete novice to NR and I’m not finding it that intuitive. YET. (I have got a motion sensor sending it’s state change to Pushover but not how to change the actual text message. I am trying). 
My thinking is I can define virtual devices then play in NR.
This way it will have no impact on my current setup.
If so, what would be the code format and where would it be stored.
I appreciate we are in beta and we need to walk before we can run but thought I’d ask.
Thanks.
2 Likes
To change msg.payload you can use the Set-node and then feed the payload into Pushover.
Edit: For Pushover I’m using Set-nodes similar to these…
3 Likes
There’s some information in the docs for this, but @april.brandt is the one to give you a good and understandable answer. I’m sure she’ll get back to you in her evening.
4 Likes
Thanks for this. Much appreciated.
I’ll keep playing… 
I did a search and a quick scan but nothing came up.
I’ll revisit and see what I can find.
Thankyou.
1 Like
@bobbles load the hubitat nodes through manage pallet. Connect through maker. You can disable a few simple automations in HE. Run them through CORE for experience then swap back if you have to walk away. Just disable the flow in NR if you dint have it perfected and go back. When you get ready to move things the flows are built. No impact.
My previous response was a quick solve.
You can do this through a function or through a change node like Carl explained. I’m now at my full time job, but I think that @RRodman would be able to give you a few intuitive examples here today so that you can dive back in later when you have time.
Although this would definitely get your feet wet, There’s no satisfaction in seeing a message or seeing how your devices will work. That’s why I recommend connecting through HE with the nodes through maker. The reward is sweeter
I’ll be the bearer of bad news… there is no way to add a virtual device to CORE itself at this time.
Now having said that I need to clarify a bit… There are several ways you could create what amounts to a virtual device on CORE, however there arent any simple steps to give you a virtual device like your used to with hubitat.
We can fake a virtual device in Z2M using null settings for everything but the network key and id, or we can send data to a mqtt topic simulating a devices output, even replay recorded data back onto our system, BUT there likely won’t be a simple way to create and utilize “virtual devices” until the CORE main stuff rolls out in the future.
What I would recommend you do for now to create virtual devices without a bunch of headaches or complicated steps… Use hubitat to create your virtual switches etc and then use them in nr etc for now.
The only current real world use i have for virtual devices is to create switches that can be triggered via google so granny can control things via voice.
Now there is a lovely little feature in node-red called context data, and using this you can also reproduce the majority of the functions you would have used a virtual switch for in HE.
Unfortunately I do not have a simple to follow example in my flows, so I cant share a flow demonstrating this at the moment. I’ll try to come up with an easy example or two to share with you guys today 
1 Like
OK. It looks like this going to make things over complicated IMHO.
If things are going to change/improve in the future then I’ll just sit and wait.
I have been playing with MakerAPI but a contact sensor on HE that I can access in NR on CORE is not updating without my intervention. It’s probably how I have things set but I will keep playing and I’m sure I will get there.
I can shift some devices for my very basic automations to CORE and just disable those devices on HE in case I need to fall back, which with zigbee is relatively easy.
Thanks for all the input.
Here is a very simple flow that can be used to send text notifications via either pushover (paid) or pushbullet (free).
What the flow does is as follows… When the motion sensor sends data we put that through a switch that only allows messages to pass if they contain a value of true on msg.payload.occupancy. If the value of true is present (meaning motion is detected) then we use a change node to set msg.payload to the alert message we want to send, and then we output that to the actual pushover node which handles sending the message to our devices.
Code Block
[{"id":"e679a9b8e69530a1","type":"zigbee2mqtt-in","z":"e9ee4b8c4cc419ef","name":"","server":"6c5abdd60ef1d8af","friendly_name":"Kitchen Motion 1 (iL07_1)","device_id":"0xd0cf5efffe53f6f0","state":"occupancy","outputAtStartup":true,"filterChanges":true,"enableMultiple":false,"x":150,"y":140,"wires":[["36af330510be3564"]]},{"id":"36af330510be3564","type":"switch","z":"e9ee4b8c4cc419ef","name":"","property":"payload.occupancy","propertyType":"msg","rules":[{"t":"eq","v":"true","vt":"str"}],"checkall":"true","repair":false,"outputs":1,"x":370,"y":140,"wires":[["9caae5759d94625a"]]},{"id":"9caae5759d94625a","type":"change","z":"e9ee4b8c4cc419ef","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"Your message here","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":540,"y":140,"wires":[["1edbaf06ad48e09d","58d1094b70fd7b1b"]]},{"id":"bdc2c57dcc1b6858","type":"group","z":"e9ee4b8c4cc419ef","name":"Pushover","style":{"stroke":"#92d04f","fill":"#92d04f","label":true,"color":"#000000"},"nodes":["58d1094b70fd7b1b","1edbaf06ad48e09d"],"x":754,"y":99,"w":172,"h":122},{"id":"58d1094b70fd7b1b","type":"pushbullet","z":"e9ee4b8c4cc419ef","g":"bdc2c57dcc1b6858","config":"621272084c7c367f","pushtype":"note","title":"Test Alert","chan":"","name":"","x":840,"y":180,"wires":[]},{"id":"1edbaf06ad48e09d","type":"pushover api","z":"e9ee4b8c4cc419ef","g":"bdc2c57dcc1b6858","keys":"20e16983c835c6e7","title":"","name":"","x":840,"y":140,"wires":[]},{"id":"621272084c7c367f","type":"pushbullet-config","name":"MAin"},{"id":"20e16983c835c6e7","type":"pushover-keys","name":"test"},{"id":"6c5abdd60ef1d8af","type":"zigbee2mqtt-server","name":"zigbeemqtt","host":"10.10.2.1","mqtt_port":"1883","mqtt_username":"","mqtt_password":"","mqtt_qos":"0","tls":"","usetls":false,"base_topic":"zigbee2mqtt"}]
1 Like
Can you explain that a bit more for me? If your referring to the text below the node not updating that is not a good indicator of activity as the person who makes the node gets to decide how and what if anything that reports.
The BEST practice in node red for knowing what data is being handled is the debug node.
Take the device you have shared via makerapi and create a flow that outputs it directly into a debug node set to display the complete message as shown below. Then trigger your motion sensor and you should see a message appear in the debug console in node red with various information (your debug will not look the same as mine and will contain far less data)
The debug node can be attached anywhere in a flow and will allow you to see the message as it travels through your flow. These little guys are amazing… have a flow that isnt quite working right, attach a debug node to each step of your flow and trigger the flow. you can trace the message each step of the way and see how it is altered in real time and adjust as needed.
I had set up MakerAPI and can see the devices I have allowed in Maker.
When I defined a recipe (is that the name) in NR the state of the contact sensor would not update in NR when opening and closing.
When I pressed the deploy button in NR it would update the CS state.
After much playing about with settings I have a solution but do not know if this should be implemented this way.
In the settings for NR on CORE, for my HE hub I have used ‘Use Websocket’ in the advanced section. It does say not recommended but thought I would give it a try.
When set like this my contact sensor on HE updates in real time in NR.
Is this correct do you know or am I getting around an issue by using this setting.
I followed these steps a while back to setup nod red for my home assistant. You can read a little about websocket comments under the Fag section of the first post.
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.
1 Like
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.
1 Like
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
2 Likes