i see. it makes sense.
I actually use bridge for just that, sending outside temp from one project to another on the inside… but as noted, I needed to write the bridge code on the sending device. I could have left the receiving one as it was and just alternated the same Temp Display Widget with the inside and outside temp (even indicating which was which) all from the sender, but I did write a seperate BLYNK_WRITE() on the receiver for the outside data.
I don’t see how you method is really any different?? But again, I am out of my depth… or more accurately experiential level. But now that I have a few more MCUs to play with, I better get busy learning all this API, Node-Red and so on 
Mehnwhile, I think the overall issue is that we already have new users totally baffled about bridge… so perhaps your title and reference to substituting Bridge is confusing me (and thus will most certainly confuse the noobs I think).
With things like Sonoffs, that have built-in relays and possibly sensors then your Wi-Fi and MQTT connection code can be written to be non-blocking (or at least to quickly try to do re-connects every so often without preventing the device from functioning if the connection fails). I use this approach with my S20s so that they can manually be turned on and off using the physical switch if everything else (except the mains power) is down.
Obviously, the more of the logic that you move out of the individual devices and into the server based Node-Red system then the easier the code tweaks are, but the less ability the devices have to continue working autonomously.
If the connection to the Blynk server is down then that doesn’t affect anything. All of my timing is done within Node-Red (using @scargill’s Big Timer node), so loss of the Blynk server doesn’t affect that.
You can also send MQTT messages from a PC or any other device on the network for that matter, so you could have a fallback system to shut everything down for example if your Node-Red/MQTT server was down.
It’s also possible to configure a fallback server if you really wanted to go down the ‘belt and braces’ route.
Pete.
Pete, but to not confuse anyone: loosing Blynk server doesn’t affect’s that, but loosing mqtt/node-red servers does! (in that particular configuration). Then if both servers are on the same device…
Everyone has it’s own methods and ideas, and IMHO it is good to program devices the way, they are always operational (well, with mains supplied 
) moving to server only non critical tasks (be it some automation and “comfort scenario” tasks 
)
Correct.
I don’t run a Blynk local server, as I’m happy with the up-time of the cloud server and I can control devices in other ways (Alexa voice commands, physical buttons on devices, sending an MQTT message from my phone or PC, Node-Red dashboard, Nextion touch screen etc) on the rare occasions that the Blynk cloud server is down.
Pete.
Last offtop: what open source fw (or perhaps your own?) are you running on ESP nodes?
ok, @Gunner, i think i figured out the source of your misunderstanding…
you probably think that one has to use BOTH functions to work. one on the master (target) and one on slave device. but this is NOT THE CASE! the 2 functions are independent, on is to write and one is to read. they do not have to be used in pairs.
- example #1:
to read any pin on any device, you just have to call this function:
String remoteTemp = APIreadDevicePin(String token, String pin);
thats all, no any specific code needed on the target device! (you actually request the info from the blynk server)
- example #2:
to write (update) a value on a remote device (lets say want to turn off a relay), you just call:
APIwriteDevicePin(String token, String pin, String value);
again, no specific code needed on target. you talk to the blynk server.
hope this makes sense after all…
OK, so you have basicly semi-automated an API call, which otherwise would have been done via a browser?
Also, to confirm for them poor noobs… by “any pin” you are referring to Virtual Pins, not direct access of physical pins (I know this, but others may not understand). 
if you’re asking from me, i have wrote my own esp firmware from scratch - it is made especially for sonoff devices, based on my previous experience what functionality is the most often needed by clients and what functionality is useful.
i’ve created some sort of “library” (a core module) of the firmware which contains the vast majority of the needed functionality (ota, debug, offline mode, automatic detection of the common sensors on every gpio, physical buttons, lots of system parameters , etc), and it is applicable to several sonoff devices: basic, thXX, 4ch, s20, slapher, etc. it is not applicable to devices with dual mcu (one esp + one exotic thing) like the dual, 4ch pro, etc.
with this “core” module #included in the sketch, all the basic features are covered. if a client needs specific or personalised logic, i can add those to the sketch, in independent functions.
This is growing interesting… but I wonder if this topic is more suited for the Lounge?
yes, something like that!
i refer to any pin not only virtual pins!
see the api docs:
Not sure if this question was meant for me?
I’m running mu own firmware. ESP Wi-Fi and PubSub client then custom code to send a status message on boot then to monitor certain MQTT message streams and act on the messages that are received.
Where I have sensors or physical push buttons then the data from these is also sent by MQTT messages.
I’m using this system to control my heating/cooling and outside lighting. It also gets data from a weather station on the roof and I’ll soon be adding a gate entry system as well. The main controller for the heating/cooling is a Nextion touch screen and this also displays some weather data. I have a homemade MQTT to infrared bridge to control my aircon and fans, and I’ll soon be adding a homemade 433mhz to MQTT bridge to control gate entry and outside lighting from a remote fob.
Indoor temperature/humidity senors are simply stand alone units with a sensor connected to a Wemos D1 Mini. The weather station is a bit more complex, but does the same task - sending readings via MQTT every 5 seconds or so.
I’ll do a bit of a write-up on the system soon, but I doubt that sharing firmware and Node-Red code will be meaningful to many people.
Pete.
Got ya about the pins… I just didn’t think the server stored physical pin data.
I have found that API Docs page rather confusing 
the structure of the api site is a bit confusing at first sight. but if you spend some time on it, it becomes quite nice. there is a “try” button on the right, so, you can try any functionality “on the flight”. for example, for digital pins it returns this:
https://blynk-cloud.com/4ae3851817194e2596cf1b7103603ef8/update/D8?value=1
as i said before, i never used non-virtual pins in my projects, but i guess it should work, if it is shown in the api. you can experiment for yourself.
there is also an overseen feature of the api, in bottom left there is the “get project” button, which returns all the info about a project, like this:
{
"id": 125564119,
"name": "New Project",
"createdAt": 0,
"updatedAt": 0,
"widgets": [
{
"type": "TWO_AXIS_JOYSTICK",
"id": 1036300912,
"x": 0,
"y": 4,
"color": -308477697,
"width": 5,
"height": 4,
"pins": [
{
"pin": 15,
"pwmMode": false,
"rangeMappingOn": false,
"pinType": "ANALOG",
"value": "1",
"min": 0,
"max": 255
},
{
"pin": 15,
"pwmMode": false,
"rangeMappingOn": false,
"pinType": "ANALOG",
"value": "2",
"min": 0,
"max": 255
}
],
"split": true,
"autoReturnOn": true,
"portraitLocked": false
},
{
"type": "BUTTON",
"id": 1036300899,
"x": 5,
"y": 0,
"color": 616861439,
"width": 2,
"height": 2,
"pinType": "DIGITAL",
"pin": 8,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"value": "0",
"pushMode": true
},
{
"type": "LED",
"id": 1036300908,
"x": 4,
"y": 0,
"color": 1602017535,
"width": 1,
"height": 1,
"label": "gggg",
"pin": -1,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"frequency": 0
},
{
"type": "LED",
"id": 1036300904,
"x": 7,
"y": 0,
"color": 1602017535,
"width": 1,
"height": 1,
"pinType": "VIRTUAL",
"pin": 2,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"frequency": 0
},
{
"type": "TIMER",
"id": 276297114,
"x": 0,
"y": 1,
"color": -308477697,
"width": 3,
"height": 1,
"pinType": "DIGITAL",
"pin": 0,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"startTime": 75600,
"startValue": "dw\u00000\u00001",
"stopTime": 75599,
"stopValue": "dw\u00000\u00000"
},
{
"type": "LED",
"id": 1036300903,
"x": 4,
"y": 1,
"color": 1602017535,
"width": 1,
"height": 1,
"pinType": "VIRTUAL",
"pin": 1,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"frequency": 0
},
{
"type": "SLIDER",
"id": 1036300911,
"x": 0,
"y": 0,
"color": -308477697,
"width": 4,
"height": 1,
"pinType": "DIGITAL",
"pin": 3,
"pwmMode": true,
"rangeMappingOn": false,
"min": 0,
"max": 255,
"value": "87"
},
{
"type": "GRAPH",
"id": 1036300905,
"x": 0,
"y": 2,
"color": -308477697,
"width": 8,
"height": 2,
"pinType": "VIRTUAL",
"pin": 5,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 1023,
"isBar": true,
"frequency": 0
},
{
"type": "LED",
"id": 1036300902,
"x": 3,
"y": 1,
"color": 1602017535,
"width": 1,
"height": 1,
"pinType": "VIRTUAL",
"pin": 0,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"frequency": 0
},
{
"type": "DIGIT4_DISPLAY",
"id": 1036300913,
"x": 5,
"y": 4,
"color": -308477697,
"width": 2,
"height": 1,
"pinType": "ANALOG",
"pin": 14,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 1023,
"frequency": 1000
},
{
"type": "BUTTON",
"id": 1036300914,
"x": 5,
"y": 5,
"color": 616861439,
"width": 2,
"height": 2,
"pinType": "DIGITAL",
"pin": 1,
"pwmMode": false,
"rangeMappingOn": false,
"min": 0,
"max": 0,
"value": "1",
"pushMode": false
},
{
"type": "NOTIFICATION",
"id": 1036300915,
"x": 5,
"y": 7,
"width": 2,
"height": 1,
"androidTokens": {
"uid": "token"
},
"notifyWhenOffline": false,
"priority": "normal"
},
{
"type": "EMAIL",
"id": 1036300916,
"x": 5,
"y": 9,
"width": 2,
"height": 1
}
],
"boardType": "Arduino UNO",
"keepScreenOn": false,
"isShared": false,
"isActive": true
}
1 Like
@PeteKnight, @wanek Thank You both! I was too lazy too write my own firmware, so I “learnt” and adopted an open source which i kinda like now 
i do not say that “my firmware” is better in any means or it worths writing your own, because i do not have any terms for comparison. i have heard about tasmota, scargill, etc, but never tested them.
writing the own version has the advantage that you can learn a lot and can be perfectly tailored to your needs. however, it is quite time consuming, sometimes can give lots of headache and probably not so professional as the above ones - i do not know.
what i can tell, that after 8+ months of testing and development (it is at version 57 yet) it works quite stable and reliably. if there is a good quality router / wifi connection, i have devices which are online for 4 weeks or more without crash or restarts. that is ok for me. however, it is still in continuous development.
the drawback is, that i never had the time to write a proper documentation about it, so for another person it would be quite challenging to learn 
but maybe sometimes i will have time for that…
1 Like
Hi @wanek, why are you stripping the payload when reading?
http://blynk-cloud.com/xxxxxxx/get/10 returns “Invalid token” as expected. However, payload returns “valid token” as the first 2 characters are removed.
neither it is worse! I’m using Espurna, but it doesn’t matter. The point is, all this is just a “top layer” of this sandwich, so perhaps more important than this “ham” on top, is the “bread” beneath And sometime it is “stale”, at least…
As well as analysing 3-party code, so “pick your choice” And there are sometime flaws that needs correction/improvements too…
1 Like
http://blynk-cloud.com/4ae3851817194e2596cf1b7103603ef8/get/V10 i’ve got [“0”]
to interpret the received string and to be able to convert to int, i had to get rid of the [" and "] part. but if you have any better idea or solution, i’m open to critics
so how do you pass on a float? I’m trying to cast it to a string but I keep getting errors. And then there’s the other way round of course… string to float.